[cfe-dev] feasibility of C++ to inline-assembly using clang

David Tweed david.tweed at gmail.com
Sun Mar 14 22:14:21 PDT 2010


On Mon, Mar 15, 2010 at 4:48 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Sun, Mar 14, 2010 at 8:57 PM, David Tweed <david.tweed at gmail.com> wrote:
>
> Umm, are you planning on making LLVM support NativeClient-style code
> generation?  Unless I'm mistaken, general inline asm will make your
> program fail validation by the NativeClient sandbox.

I don't understand much about general x86 assembly, so the following
reasoning may be complete and utter boll^H^H^H^Hrubbish: my
understandnig was that NaCl requires inserting NOP padding at various
points to ensure that you can't generate dangerous instructions by
jumping into the middle of an instruction, modifying the calling
convention and prohibiting certain dangerous instructions that I
didn't think ordinary computation would result in anyway. So I'd
assumed that the modified g++ would insert padding bytes into inline
assembly, which was the only thing that would potentially cause the
native client to not output a verifiable binary. But I ought to ask on
the NaCl list if that understanding is correct.

> Also, I don't see the point; why can't you just put the
> performance-sensitive function in its own file, compile it to a .s
> file, and add that to your project?

Here again comes a possible weak link in my understanding: presumably
even a C-style function in C++ has to be name mangled (as you don't
know if there's another overloading in a different translation unit),
and I wasn't sure if the details of that were guaranteed to be
compatible between nearby compiler releases. (I only really know the
rule of thumb "compile everything C++ with the same compiler version
or expect trouble", but thinking about it things can't be being
changed that rapidly.) Just keeping all the uncontroversial,
performance intensive code separate from the non-performance
intenseive code that uses C++ functionality and compiling those to .s
files may be the best solution.

Thanks for the thoughts,


-- 
cheers, dave tweed__________________________




More information about the cfe-dev mailing list