Re: LTO & top-level ASM

[Ian Lance Taylor <iant at google dot com>]

On Tue, Mar 25, 2014 at 3:26 AM, Martin LiÅka <mliska@suse.cz> wrote:
> The code resides in Chromium project, please see full source code:
> https://github.com/scheib/chromium/blob/master/sandbox/linux/seccomp-bpf/syscall.cc

The easy workaround is to make SyscallAsm global.  And frankly I would
put it in a .S file.  You aren't getting any advantage by wrapping a
large function as a top-level asm.

I'm not opposed to fixing this in GCC somehow, but you are trying to
do something rather tricky.  You are providing two different unrelated
asm statements and insisting that they appear in the same file,
specifically to avoid function cloning.  GCC gives you the tools you
need to make this work but you don't want to use them because clang
doesn't support them.  So you're asking us for a GCC workaround for a
clang workaround.  Since we're already into double workarounds, it's
not clear to me whether there is a bug here or not.  Just make the
symbol global.

Ian

> On 03/24/2014 06:34 PM, Ian Lance Taylor wrote:
>>
>> On Mon, Mar 24, 2014 at 6:26 AM, Martin LiÅka <mliska@suse.cz> wrote:
>>>
>>>     I've been solving undefined symbols related to:
>>> http://gcc.gnu.org/PR57703. In chromium there's a following inline asm:
>>>
>>> asm(".type Syscall, @function\n" ...);
>>>
>>> intptr_t SandboxSyscall(...)
>>> {
>>>     asm volatile("call SyscallAsm");
>>> }
>>
>> Can you explain why you need that asm statement?
>>
>> Normally the .type declaration would appear where the Syscall symbol
>> is defined.  Why are you putting it elsewhere?
>>
>> Ian
>
>