https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Martin Liška from comment #6) > There's how gold's ICF works for test attached by Jakub: > > gcc --version: > gcc version 5.0.0 20141016 (experimental) (GCC) > > ld --version: > GNU gold (GNU Binutils 2.24.51.20141010) 1.11 > > $ gcc icf-gdb.c -c -g --function-sections > $ gcc icf-gdb.o -o a.out -Wl,--icf=all,--print-icf-sections > ... > ld: ICF folding section '.text.f2' in file 'icf-gdb.o' into '.text.f1' in > file 'icf-gdb.o' > ... > > dwarfdump a.ou shows: > < 1><0x00000059> DW_TAG_subprogram > DW_AT_name f1 > DW_AT_decl_file 0x00000001 > /home/marxin/Programming/testcases/icf-gdb.c > DW_AT_decl_line 0x00000005 > DW_AT_prototyped yes(1) > DW_AT_type <0x00000052> > DW_AT_low_pc 0x00400546 > DW_AT_high_pc <offset-from-lowpc>115 > DW_AT_frame_base len 0x0001: 9c: > DW_OP_call_frame_cfa > DW_AT_GNU_all_call_sites yes(1) > DW_AT_sibling <0x000000e2> > > > and: > < 1><0x000000e8> DW_TAG_subprogram > DW_AT_name f2 > DW_AT_decl_file 0x00000001 > /home/marxin/Programming/testcases/icf-gdb.c > DW_AT_decl_line 0x00000015 > DW_AT_prototyped yes(1) > DW_AT_type <0x00000052> > DW_AT_low_pc 0x00400546 > DW_AT_high_pc <offset-from-lowpc>115 > DW_AT_frame_base len 0x0001: 9c: > DW_OP_call_frame_cfa > DW_AT_GNU_all_call_sites yes(1) > DW_AT_sibling <0x00000171> > > If I tried to put breakpoint in GDB to f2, breakpoint is triggered 4 times > with back-trace from all functions f3-f6. > Example: > #0 f1 (x=0x7fffffffda10) at icf-gdb.c:24 > #1 0x00000000004005d1 in f3 (x=0x7fffffffda10) at icf-gdb.c:33 > #2 0x0000000000400657 in main () at icf-gdb.c:44 > > > Maybe I miss something, but gold also does not support correct DWARF merging. > I will create issue for gold. Well, the debug info you get after ld ICF merging is better than what GCC creates for ICF merging right now, though still not ideal, but as gold likely doesn't want to rewrite debug info (which is costly operation), it can't do much more than that, while GCC can. As you can see above, at least you do have two separate DW_TAG_subprogram for f1/f2, vars/lexical blocks/parameters/inline functions in them in a good shape. Supposedly the DW_TAG_GNU_call_site info is present and correct too, so the debugger has the option to find out in which function it is, but that doesn't necessarily mean gdb has such support present. What is broken with ld ICF merging is supposedly .debug_line, for both functions you are pointed to the same portion of .debug_line, and that portion contains two sets of line instructions for the same spots, not sure if it can be considered valid or how would gdb be able to find out which function is which in there.
