Summary: | =sys-devel/gdb-8.1.1: "-ftracer" and "-O3" gives Error: symbol `start_amd64_void_call_2_a' is already defined | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marcin Mirosław <bug> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | jstein, nick |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Marcin Mirosław
2018-07-10 10:05:11 UTC
Thank you for the report. Please recompile and *attach* the logfiles as described on https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket Please reopen this ticket (Status:unconfirmed) afterwards. Created attachment 539082 [details]
build.log
-ftracer is incompatible with some of inline assembly that defines labels as -ftracer duplicates statements as-is. Simplest workaround would be to add 'strip-flags -ftracer' to gdb ebuild. Being a workaround it will not help -fprofile-use users. I wonder if there is a cheap way to make assembly more duplication-friendly or forbid duplication entirely (like marking asm statement volatile). (In reply to Sergei Trofimovich from comment #3) > -ftracer is incompatible with some of inline assembly that defines labels as > -ftracer duplicates statements as-is. > > Simplest workaround would be to add 'strip-flags -ftracer' to gdb ebuild. > Being a workaround it will not help -fprofile-use users. > > I wonder if there is a cheap way to make assembly more duplication-friendly > or forbid duplication entirely (like marking asm statement volatile). Found it. Duplication cases are explicitly listed in https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html: """ Under certain circumstances, GCC may duplicate (or remove duplicates of) your assembly code when optimizing. This can lead to unexpected duplicate symbol errors during compilation if your asm code defines symbols or labels. Using ‘%=’ (see AssemblerTemplate) may help resolve this problem. ‘%=’ Outputs a number that is unique to each instance of the asm statement in the entire compilation. This option is useful when creating local labels and referring to them multiple times in a single template that generates multiple assembler instructions. """ Unfortunately gdb wants to define labels explicitly and refer them from C code in EMIT_ASM and EMIT_ASM32 macros. I think it would make sense to move label definition out into a top-level definition. *** Bug 376455 has been marked as a duplicate of this bug. *** |