[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #14 from Andrew Pinski --- Dup of bug 46820. *** This bug has been marked as a duplicate of bug 46820 ***
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|WAITING |NEW --- Comment #13 from Martin Liška --- No, it's a known and confirmed problem.
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- Any reason to keep this in WAITING?
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Martin Liška changed: What|Removed |Added CC||Hi-Angel at yandex dot ru --- Comment #11 from Martin Liška --- *** Bug 89147 has been marked as a duplicate of this bug. ***
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 64420 has been marked as a duplicate of this bug. ***
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 --- Comment #10 from Alexander Monakov amonakov at gcc dot gnu.org --- 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?
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 60690 has been marked as a duplicate of this bug. ***
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||gmarkhor at gmail dot com --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 48947 has been marked as a duplicate of this bug. ***
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- 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.
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- 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.
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #4 from Martin Liška marxin.liska at gmail dot com ---
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'
SyscallAsm:
namespace playground2 {
asm volatile(
# 76 ../../sandbox/linux/seccomp-bpf/syscall.cc
.text\n
.align 16, 0x90\n
.type SyscallAsm, @function\n
SyscallAsm:.cfi_startproc\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
ret\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
syscall\n
2:ret\n
.cfi_endproc\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.
Martin
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 --- Comment #2 from Martin Liška marxin.liska at gmail dot com --- Created attachment 30374 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30374action=edit syscall.cc
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 --- Comment #3 from Martin Liška marxin.liska at gmail dot com --- Created attachment 30375 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30375action=edit Preprocessed syscall.cc
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-25 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- (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?
