Bug 57703 - Assembler function definition moved to a different ltrans then call
Summary: Assembler function definition moved to a different ltrans then call
Status: RESOLVED DUPLICATE of bug 46820
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
: 48947 60690 64420 89147 (view as bug list)
Depends on:
Blocks: 57208
  Show dependency treegraph
Reported: 2013-06-24 20:49 UTC by Martin Liška
Modified: 2022-01-01 22:58 UTC (History)
10 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-25 00:00:00

syscall.cc (3.16 KB, text/x-c++src)
2013-06-26 12:45 UTC, Martin Liška
Preprocessed syscall.cc (66.85 KB, text/x-c++src)
2013-06-26 12:48 UTC, Martin Liška

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liška 2013-06-24 20:49:35 UTC
SandboxSyscall calls SyscallAsm that is an assembler function defined in the same file: syscall.cc.

dump grep:
grep SyscallAsm *:
out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm
out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm
out/Release/nacl_helper.ltrans0.s:.type SyscallAsm, @function
out/Release/nacl_helper.ltrans0.s:9:.size SyscallAsm, 9b-SyscallAsm
out/Release/nacl_helper.ltrans1.s:call SyscallAsm
out/Release/nacl_helper.ltrans1.045i.cp:call SyscallAsm

Linker error:
nacl_helper.ltrans1.ltrans.o: In function `playground2::SandboxSyscall(int, long, long, long, long, long, long)':
nacl_helper.ltrans1.o:(.text+0x4503): undefined reference to `SyscallAsm'
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: nacl_helper.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined symbol `SyscallAsm' can not be used when making a shared object; recompile with -fPIC
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Dumps link:

When compiled with --param lto-partitions=1 no problem is encountered.
Comment 1 Richard Biener 2013-06-25 08:00:20 UTC
(In reply to Martin Liška from comment #0)
> SandboxSyscall calls SyscallAsm that is an assembler function defined in the
> same file: syscall.cc.

If it is in a toplevel asm() then this is a know missed feature of
toplevel asm()s - you cannot specify what symbols they declare.

Can you attach preprocessed source of syscall.cc?
Comment 2 Martin Liška 2013-06-26 12:45:04 UTC
Created attachment 30374 [details]
Comment 3 Martin Liška 2013-06-26 12:48:32 UTC
Created attachment 30375 [details]
Preprocessed syscall.cc
Comment 4 Martin Liška 2014-03-18 16:05:11 UTC
Hm, it looks that there's an usage of top-level function chromium binary:

/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function sandbox::Die::ExitGroup(): error: undefined reference to 'SyscallAsm'
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function sandbox::Die::ExitGroup(): error: undefined reference to 'SyscallAsm'
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function sandbox::Die::SandboxDie(char const*, char const*, int): error: undefined reference to 'SyscallAsm'
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function sandbox::Trap::SigSys(int, siginfo_t*, void*): error: undefined reference to 'SyscallAsm'

namespace playground2 {

  asm volatile(
# 76 "../../sandbox/linux/seccomp-bpf/syscall.cc"
            ".align 16, 0x90\n"
            ".type SyscallAsm, @function\n"

            "test %rax, %rax\n"
            "jge  1f\n"

            "call 0f;   .cfi_adjust_cfa_offset  8\n"
          "0:pop  %rax; .cfi_adjust_cfa_offset -8\n"
            "addq $2f-0b, %rax\n"

          "1:movq  0(%r12), %rdi\n"
            "movq  8(%r12), %rsi\n"
            "movq 16(%r12), %rdx\n"
            "movq 24(%r12), %r10\n"
            "movq 32(%r12), %r8\n"
            "movq 40(%r12), %r9\n"


          "9:.size SyscallAsm, 9b-SyscallAsm\n"
# 172 "../../sandbox/linux/seccomp-bpf/syscall.cc"

If it's not supported feature, how could we handle such situation in LTO? Assembler functions are commong in all kind video/audio codecs which are often added to firefox/chromium.

Comment 5 Richard Biener 2014-03-19 11:02:58 UTC
This is just totally broken and not supportable with LTO.  We'd need to amend
toplevel asm syntax to list defined and used symbols, but that doesn't fix
existing uses.

The proper fix is to excempt these files from LTO or move those assembler
functions to separate TUs (preferably assembler TUs...).

Honza also had the idea of trying to parse the assembler string for
"obvious" symbol definitions / uses.
Comment 6 Martin Jambor 2014-03-25 10:38:56 UTC
I believe this could be dealt with by forcing all inline assembly from
one compilation unit (including those which were inlined) to end up in
one partition.  If any of them defines a hidden symbol, the assembler
will see it.

This would of course probably be quite ugly hack to the partitioner.
But perhaps we could only enable it by a switch and/or proceed only if
there is a top level assembler in any particular compilation unit.
I suppose definitions of symbols in non-top-level inline assembly is
already fragile because functions can be inlined/cloned etc.
Comment 7 Markus Trippelsdorf 2014-09-06 10:21:29 UTC
*** Bug 60690 has been marked as a duplicate of this bug. ***
Comment 8 Markus Trippelsdorf 2014-09-06 10:29:53 UTC
*** Bug 48947 has been marked as a duplicate of this bug. ***
Comment 9 Markus Trippelsdorf 2014-12-28 08:52:41 UTC
*** Bug 64420 has been marked as a duplicate of this bug. ***
Comment 10 Alexander Monakov 2014-12-28 10:17:15 UTC
Bug 64420, which was marked as a duplicate, presents an example where there's no diagnostics at build time (linking succeeds), but the resulting code is wrong and will fail at runtime.

I believe the correct fix would be to disable LTO partitioning in a TU that contains top-level asms (but in that TU only).  Is there something wrong with such approach?
Comment 11 Martin Liška 2019-02-04 13:06:16 UTC
*** Bug 89147 has been marked as a duplicate of this bug. ***
Comment 12 Eric Gallager 2020-09-21 00:03:08 UTC
Any reason to keep this in WAITING?
Comment 13 Martin Liška 2020-09-21 07:12:21 UTC
No, it's a known and confirmed problem.
Comment 14 Andrew Pinski 2022-01-01 22:58:47 UTC
Dup of bug 46820.

*** This bug has been marked as a duplicate of bug 46820 ***