[Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687 Lassi Tuura lat at cern dot ch changed: What|Removed |Added CC||lat at cern dot ch --- Comment #1 from Lassi Tuura lat at cern dot ch 2011-10-11 09:25:24 UTC --- FWIW, I don't think this is a bug in the compiler. With -fvisibility=hidden a promise is made that bar::foo() is internal to the shared library, and if the compiler generates virtual function table for bar, it needs foo too. At least on a system I tested, RHEL5-derived system with GCC 4.6.1 and binutils 2.21.1 gold as the linker, the reason there's no unreferenced symbols without -flto is simply that no code what so ever is getting generated for 'bar'. In fact no code at all is emitted for test.cc. I assume the compiler just decides the class is irrelevant to the compilation unit, which seems entirely reasonable choice to me -- otherwise it'd be generating code for loads of types from headers which are never used in a particular compilation unit. With 4.6.x LTO presumably this pruning doesn't happen, or isn't complete enough, and/or isn't garbage collected at link phase as unreferenced, so the bar::foo reference remains and becomes unsatisfied symbol - which seems reasonable to me. Perhaps it's a quality issue that unreferenced types cause code to be generated, but IMHO is not a bug in the compiler. If I change the code so it forces a reference generated for bar, so the bar virtual function table gets generated, triggering getFoo() to be compiled, I get the same undefined symbol without LTO with GCC 4.6.1 too. I didn't try with GCC trunk, so can't comment on why the reference isn't seen there.
[Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687 --- Comment #4 from Lassi Tuura lat at cern dot ch 2011-10-11 12:00:47 UTC --- Right, as far as I can tell at the moment visibility option is somewhat peripheral to the issue. The main difference you see with LTO vs. no LTO appears to be whether code for the type is generated at all. As far as I can tell, once the compiler decides to generate code for 'bar', you get the same behaviour in all cases. The visibility controls only apply after that. Whether it's an issue that LTO in 4.6.x generates references to otherwise unreferenced types I can't say. I'd say it is not invalid, though perhaps undesirable. But once code is generated for types like 'bar', the app needs to make sure it uses correct visibility controls. As far as I understand, the actual upstream problem is that 'bar' really comes from a header file, from another package. The #include for that header is not using visibility push/pop to reset visibility to 'default', so the header inherits the 'hidden' visibility from command line. At the moment, without visibility directives, there's a side effect that 4.6.x LTO generates references to otherwise unused types from those headers, resulting in link errors. But I'd suggest this usage is quite fragile - the moment anything from those headers is actually referenced, the app needs to be fixed to reset visibility to 'default' around #includes anyway (because the module in question is being compiled with -fvisibility=hidden). Of course if 4.6.x can be amended to prune types from LTO more aggressively, it will help to avoid this particular issue. I'm just not sure it will actually fix all the upstream problems, I rather suspect some types coming from headers are actually referenced in ways which in the end will require full visibility management in the source code.
[Bug lto/48384] lto, linker-plugin and optimization clutter the stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48384 Lassi Tuura lat at cern dot ch changed: What|Removed |Added CC||lat at cern dot ch --- Comment #6 from Lassi Tuura lat at cern dot ch 2011-05-14 15:41:35 UTC --- I think this is an issue I previous looked at for Vincenzo, and concluded that LTO-generated binary has unwind info referring to the wrong ELF base section, .eh_frame, rather than .text, completely messing up any attempt to unwind. I don't have immediate access to the exact tool chain used for this bug report so can't replicate the necessary info right now, but I've attached a previous analysis I sent to Vincenzo. If this isn't sufficient to put investigation on the right track, I'll get together with Vincenzo next week and we will generate the necessary unwind info dumps for the specific test case he added here before. === At any rate the unwind info is completely messed up. For example from readelf -Wwf libfoo_hlto.so we have a claim there is a function at pc=07a0..086f. 0020 fea8 001c FDE cie=0008 pc=07a0..086f DW_CFA_advance_loc: 2 to 07a2 DW_CFA_def_cfa_offset: 16 DW_CFA_offset: r12 (r12) at cfa-16 DW_CFA_advance_loc: 4 to 07a6 DW_CFA_def_cfa_offset: 24 [...] But the only function of any significance in that library is not at that address, as shown by objdump -d libfoo_hlto.so. The FDE program looks correct otherwise, just is at wrong address. 0640 _Z2goiPKi: 640: 41 54 push %r12 642: 49 89 f4mov%rsi,%r12 645: 55 push %rbp 646: 8d 6c 3f 01 lea0x1(%rdi,%rdi,1),%ebp 64a: 53 push %rbx [...] 6ff: 5b pop%rbx 700: 5d pop%rbp 701: 41 5c pop%r12 703: c3 retq 704: e8 57 fe ff ff callq 560 sqrt@plt 709: c5 f9 28 c8 vmovapd %xmm0,%xmm1 70d: eb b9 jmp6c8 _Z2goiPKi+0x88 70f: 90 nop In fact there's nothing at all at the CIE range 07a0..086f - the address is in unwind info table itself (.eh_frame), not in the code. So it looks like whatever is generating this unwind info is generating wrong address references. $ readelf -WS libfoo_hlto.so There are 29 section headers, starting at offset 0x1100: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [...] [14] .eh_frame PROGBITS0778 000778 58 00 A 0 0 8 [15] .eh_frame_hdr PROGBITS07d0 0007d0 14 00 A 0 0 4 [...] Looks like your tool chain is broken. I don't know why.
[Bug c/48597] x86-64 unwind register save location misses half-register write?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48597 --- Comment #1 from lat at cern dot ch 2011-04-14 07:53:27 UTC --- For completeness I didn't look for unwind inaccuracies with half-register writes other than the exact form (v)movd %xmmN,%ebp. It's entirely possible this bug happens only with %xmm - %ebp writes, but also that it is more widespread. At any rate, this is the first I've noticed this problem, and the specific issue I found only exists in four functions - but unfortunately our code hits those math functions quite hard and inability to unwind through them is awkward.
[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48597 --- Comment #8 from Lassi Tuura lat at cern dot ch 2011-04-15 05:40:33 UTC --- I confirm glibc 2.13 built with gcc 4.6.1 20110408 snapshot patched with gcc46-pr48597.patch results in correct unwind info for __ieee754_lgammaf_r. I checked all the locations using (v)movd %xmmN,%ebp pattern, and the unwind info is now correct everywhere. Haven't run any of the newly compiled code yet, will do that later.
[Bug c/48597] New: x86-64 unwind register save location misses half-register write?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48597
Summary: x86-64 unwind register save location misses
half-register write?
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@cern.ch
On RHEL6 x86-64, GCC compiled libm has inaccurate unwind info for
__ieee754_rem_pio2f() as called by tanf(). The problem is GCC knows %rbp is
saved, and correctly describes the save location, but delays emitting the info
from actual register save to a later address, missing write to half-size
register alias %ebp in between. If unwinding starts in the in-between region,
%rbp is not restored correctly off the stack, leading to problems later in a
stack frame with CFA defined as offset off %rbp.
The start of assembly and unwind info for __ieee754_rem_pio2f follows.
Dump of assembler code for function __ieee754_rem_pio2f:
0x735b1080 +0: push %rbp
0x735b1081 +1: movd %xmm0,%ebp
0x735b1085 +5: push %rbx
0x735b1086 +6: mov%ebp,%ecx
0x735b1088 +8: mov%rdi,%rbx
0x735b108b +11: and$0x7fff,%ecx
0x735b1091 +17: sub$0x18,%rsp
1d30 003c 1d34 FDE cie= pc=0002c080..0002c3ba
DW_CFA_advance_loc: 1 to 0002c081
DW_CFA_def_cfa_offset: 16
DW_CFA_advance_loc: 5 to 0002c086
DW_CFA_def_cfa_offset: 24
DW_CFA_advance_loc: 5 to 0002c08b
DW_CFA_offset: r3 (rbx) at cfa-24
DW_CFA_offset: r6 (rbp) at cfa-16
As you can see at 0x2c081 / 0x735b1081 a movd %xmm0, %ebp instruction
writes to %rbp, but the unwind info describes the save location for the
register only at 0x2c08b / 0x735b108b.
It's easiest to demo the effect in GDB; the original problem occurred in a
sampling profiler which uses libunwind. See (1) for the full GDB session trace.
To replicate this, you need a) a call to tanf() with an argument requiring
__ieee754_rem_pio2f() call, b) a function above tanf() with CFA based on %rbp
(SimpleNavigableLayer::wellInside() in (1)), and c) a stack walk within the
three instructions with inaccurate unwind info.
RHEL6 glibc seems to be built with GCC 4.4.4 (2). The entire libm has just four
instances of 'movd %xmmN,%ebp', in __ieee754_asinf, __ieee754_j1f,
__ieee754_lgammaf_r, __ieee754_rem_pio2f; all with the same unwind info issue.
In GLIBC 2.13 compiled with GCC 4.6.x pre-release (3), the first three still
have a 'vmovd %xmmN,%ebp', plus there's one in cprojf, but none in
__ieee754_rem_pio2f. Of these only __ieee754_lgammaf_r is incorrect (4), all
others have correct unwind info - though I am not sure if they are just
'different' rather than 'fixed', see how __ieee754_rem_pio2f changed in (5).
If there is easy enough a fix, we have some interest in back-port to 4.4.x in
case we have any luck convincing RHEL to pick up the patch and rebuild
libc/libm.
(1)
$ gdb --args cmsRun
/home/data/runPU/TTbar_Tauola_RAW2DIGI_L1Reco_RECO_PU_lto5.py
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /data/CMSSW_4_2_0_pre6/bin/slc5_amd64_gcc451/cmsRun...(no
debugging symbols found)...done.
(gdb) b __ieee754_rem_pio2f
Function __ieee754_rem_pio2f not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__ieee754_rem_pio2f) pending.
(gdb) b 'SimpleNavigableLayer::wellInside(FreeTrajectoryState const,
PropagationDirection, ForwardDetLayer const*, std::vectorDetLayer const*,
std::allocatorDetLayer const* ) const'
Function SimpleNavigableLayer::wellInside(FreeTrajectoryState const,
PropagationDirection, ForwardDetLayer const*, std::vectorDetLayer const*,
std::allocatorDetLayer const* ) const not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 ('SimpleNavigableLayer::wellInside(FreeTrajectoryState const,
PropagationDirection, ForwardDetLayer const*, std::vectorDetLayer const*,
std::allocatorDetLayer const* ) const') pending.
(gdb) disa 1
(gdb) commands 2
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just end.
ena 1
cont
end
(gdb) r
Starting program: /data/CMSSW_4_2_0_pre6/bin/slc5_amd64_gcc451/cmsRun
/home/data/runPU/TTbar_Tauola_RAW2DIGI_L1Reco_RECO_PU_lto5.py
[Thread debugging using libthread_db enabled]
14-Apr-2011 01:22:27 CEST Initiating request to open file
file:0E1B7BC9-7E2C-E011-A37B-0018F3D096B6.root
14-Apr-2011 01:22:29 CEST Successfully opened file
[Bug c++/43498] New: -fasynchronous-unwind-tables does not seem to do anything
-- Summary: -fasynchronous-unwind-tables does not seem to do anything Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lat at cern dot ch GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug c++/43498] -fasynchronous-unwind-tables does not seem to do anything
--- Comment #2 from lat at cern dot ch 2010-03-23 18:52 --- Created an attachment (id=20174) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20174action=view) Random C source file for testing Random C source file for additional testing. Compile on Linux with and without -fasynchronous-unwind-tables, with normal compile gcc -g -std=gnu99 -W -Wall -O2 islocal.c -o islocal. No difference in readelf --debug=frames output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug c++/43498] -fasynchronous-unwind-tables does not seem to do anything
--- Comment #3 from lat at cern dot ch 2010-03-23 18:54 --- Ah, that would explain it. Does it mean that all omissions and inaccuracies in unwind information are bugs? Like the lack of unwind info for thunks? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug middle-end/43498] -fasynchronous-unwind-tables does not seem to do anything
--- Comment #5 from lat at cern dot ch 2010-03-23 18:58 --- OK, reopening bug then. -- lat at cern dot ch changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
[Bug middle-end/43498] No unwind info for thunks even with -fasynchronous-unwind-tables
--- Comment #6 from lat at cern dot ch 2010-03-23 19:04 --- Changing subject to be more descriptive of the actual bug. -- lat at cern dot ch changed: What|Removed |Added Summary|-fasynchronous-unwind-tables|No unwind info for thunks |does not seem to do anything|even with -fasynchronous- ||unwind-tables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43498
