[Bug ld/18860] New: Order of ELF symbols is not preserved

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18860

            Bug ID: 18860
           Summary: Order of ELF symbols is not preserved
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com
  Target Milestone: ---

Demangling of ELF symbols is broken in gdb, and probably not fixable (in the
general case). The problem is "What language does one demangle the symbol in?"
There is no standard, nor likely to ever be one. To make things worse GNU C++
and Java share the same demangling scheme.

One possibility to solve this is to use the language encoded in the DWARF and
use that to decide how to demangle ELF symbols in that CU. It's a bit
unfortunate to require DWARF in order to properly interpret ELF.

One heuristic gdb employs is to look at the last file symbol and assume all
symbols for that file immediately follow it, and then choose the language based
on the source file name. That no longer works (not sure it ever worked for ELF)
because the linker bunches all the file symbols together (I'm not sure if it's
sorting them somehow or what). And of course this is just a heuristic, but not
a bad one.
Arguably this isn't a linker bug, I'm not aware of a spec that says the linker
has to retain symbol order in the way gdb expects it to.

The purpose of this bug report is to document the problem,
and see if it's possible to make the linker behave the way gdb expects it to.

The linker has been working this way a long time (forever?) - I couldn't find
an existing bug - I'm guessing this isn't news to anyone, but IWBN to document
why things are the way they are and establish closure (e.g., so we can remove
this hack from gdb since it's useless and can lead to confusion in the
debugging session).

Repro:

@ruffy2:play$ cat elf-file-name.cc
extern "C" int foo ();
extern int bar ();
int
main ()
{
  return foo () + bar ();
}
@ruffy2:play$ cat elf-file-name-1.c
int
foo (void)
{
  return 0;
}
@ruffy2:play$ cat elf-file-name-2.cc
int
bar ()
{
  return 0;
}
@ruffy2:play$ gcc -c -g elf*.c elf*.cc
@ruffy2:play$ g++ elf*.o
@ruffy2:play$ readelf -s a.out
-->
...
    39: 00000000004004c0     0 FUNC    LOCAL  DEFAULT   13 frame_dummy
    40: 0000000000600e10     0 OBJECT  LOCAL  DEFAULT   18
__frame_dummy_init_array_
    41: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS elf-file-name-1.c
    42: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS elf-file-name-2.cc
    43: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS elf-file-name.cc
    44: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    45: 0000000000400728     0 OBJECT  LOCAL  DEFAULT   17 __FRAME_END__
    46: 0000000000600e20     0 OBJECT  LOCAL  DEFAULT   20 __JCR_END__
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.