Summary: | sys-devel/gdb-7.5: build fails w/-ftracer on amd64: linux-x86-low.c:2939: Error: symbol 'start_i386_void_call_2_a' is already defined | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Evan Teran <evan.teran> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED DUPLICATE | ||
Severity: | minor | CC: | jer |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build log |
Description
Evan Teran
2012-11-28 23:52:39 UTC
Created attachment 330870 [details]
build log
Drop the whole '-fomit-frame-pointer -finline-functions -ftracer' string from your C{,XX}FLAGS and try again. That worked, perhaps the ebuild should filter out these flags if they break the build? I've always considered -fomit-frame-pointer -finline-functions to be pretty tame in general, and -ftracer is a recent addition to my flags which doesn't sound like it should break things. what flag exactly is causing it to break ? looks like -ftracer, when I take that out, it builds fine. Correct me, if I'm wrong, but isn't '-fomit-frame-pointer' a bit pointless on amd64 ? That flag was needed sometimes on x86, due to register pressure in some of the packages, but shouldn't any performance gain from it be negligible on amd64 ? (In reply to comment #5) need to sort out whether it's a gcc bug or expected behavior. doubtful it is a bug in gdb (although not impossible). (In reply to comment #6) yes, it is pointless with any -O level on x86_64. even on x86, starting with gcc-4.6, it is also enabled by default. Regarding #6, while it's a little off topic I'll respond :-). Yes, starting with gcc 4.6 the frame pointer is omitted anyway, but I'm not using 4.6 or greater as my system compiler yet, so we'll assume that there would be a frame pointer were it not for that flag (for now). It certainly it has a far lesser effect on x86_64, but I wouldn't go so far as to say that it's pointless. An extra register available for general usage can really only improve the emitted code or at worst be equal in performance, I can't imagine a scenario where it would make things worse. In addition, there is the *very minor* frame pointer maintenance code which no longer needs to exist, namely. push rbp mov rbp, rsp ... mov rsp, rbp pop rbp ret I highly doubt that these 4 instructions have any really measurable effect on performance, but it's one less thing each function has to do, once again, can't makes things worse. All in all, considering that the GNU folks thought it was a good enough idea to enable by default in future versions of gcc, I consider it good enough for me :-). It's certainly never caused me any problems. In the end it's a matter of preference of course. (In reply to comment #8) the change in defaults with 4.6 affect x86 (32bit) only. x86_64 has long had this behavior by default. further, your logic is slightly flawed. "good enough for upstream 4.6" doesn't mean they suddenly changed their mind and so it is retroactively a good idea. improvements in the generation of code/debug information and register allocation is a much more likely reason as to why the default has changed. those improvements don't exist in older versions. (In reply to comment #9) Fair enough, I wasn't aware that the change in default was 32-bit only. While your right that whatever improvements triggered the change in default don't suddenly improve the older versions of the compiler, it wasn't my intention to imply that. Regardless, you still make a valid point there, 4.5 probably doesn't do as good a job managing registers as 4.6+ does. But since x86_64 has this enable by default, it's kinda a moot point, frame pointers are disabled either way ;-). I suspect this is a duplicate of 376455. The problem is the combination of both -finline-functions and -ftracer. If you remove either -ftracer or -finline-functions the problem does not arise. https://bugs.gentoo.org/show_bug.cgi?id=376455 *** This bug has been marked as a duplicate of bug 376455 *** |