Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold <gingold@adacore.com>]

On Dec 25, 2009, at 9:04 PM, Jan Kratochvil wrote:

> Hi,
> 
> Re: [RFA] Make sym_read routines handle separate debug files
> http://sourceware.org/ml/gdb-patches/2009-12/msg00117.html
> http://sourceware.org/ml/gdb-cvs/2009-12/msg00042.html
> ffb64a120e667bad7b2a79c5e617bdea7328f996
> 	* symfile.h (symbol_file_add_separate): New prototype.
> 	(find_separate_debug_file_by_buildid): Ditto.
> 	(find_separate_debug_file_by_debuglink): Ditto.
> 	* symfile.c (reread_separate_symbols): Remove.
> 	(find_separate_debug_file): Split into ...
> 	(find_separate_debug_file_by_buildid): ... this and ...
> 	(find_separate_debug_file_by_debuglink): ... this.
> 	(symbol_file_add_with_addrs_or_offsets): Do not save orig_addrs.
> 	Remove separate debug file handling.
> 	(symbol_file_add_separate): New function.
> 	(reread_symbols): Do not considere separate debug files, but free
> 	them while handling their parent.  Reindent.
> 	* coffread.c (coff_symfile_read): Handle separate object file.
> 	* elfread.c (elf_symfile_read): Ditto.
> 
> has caused a regression:
> 	echo 'void f (void) {}'|gcc -Wall -fPIC -shared -g -o a.so -x c -;objcopy --only-keep-debug a.so a.so.debug;objcopy --strip-debug --add-gnu-debuglink=a.so.debug a.so;prelink -NR a.so;echo 'extern void f (void);int main (void) { f (); return 0; }'|gcc -Wall -g -o a ./a.so -x c -;./gdb -nx -ex start -ex 'adv f' ./a
> printing now:
> 	Cannot access memory at address 0x52c
> 
> prelink will set in-file addresses to some random value while in the .debug
> file they remain zero-based.  In such case "section_offsets" below will remain
> zero because the library will (probably) get loaded at the same address as the
> file is prelinked at.  Still the .debug file must be relocated in such case.
> 
> 
> symbol_file_add_separate calls there now:
> 	0, /* No addr table.  */
> while it supplies:
> 	objfile->section_offsets, objfile->num_sections,
> 
> This cannot work as the binary file and its separate debug info file are two
> different objfiles having different number and ordering of sections.
> objfile-independent displacement format is that "addr table".

Hi,

my understanding is that separate debug info and its binary file have the same ordering of sections, or
to be more precise, the separate debug info only appends new debug sections to the binary file while
making content sections empty.

In this example, I have:

$ readelf -S a.so
There are 26 section headers, starting at offset 0x764:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .hash             HASH            000000b4 0000b4 000098 04   A  2   0  4
  [ 2] .dynsym           DYNSYM          0000014c 00014c 000130 10   A  3  10  4
  [ 3] .dynstr           STRTAB          0000027c 00027c 00006f 00   A  0   0  1
  [ 4] .gnu.version      VERSYM          000002ec 0002ec 000026 02   A  2   0  2
  [ 5] .gnu.version_r    VERNEED         00000314 000314 000020 00   A  3   1  4
  [ 6] .rel.dyn          REL             00000334 000334 000028 08   A  2   0  4
  [ 7] .rel.plt          REL             0000035c 00035c 000010 08   A  2   9  4
  [ 8] .init             PROGBITS        0000036c 00036c 000017 00  AX  0   0  4
  [ 9] .plt              PROGBITS        00000384 000384 000030 04  AX  0   0  4
  [10] .text             PROGBITS        000003c0 0003c0 000114 00  AX  0   0 16
  [11] .fini             PROGBITS        000004d4 0004d4 00001c 00  AX  0   0  4
  [12] .eh_frame         PROGBITS        000004f0 0004f0 000004 00   A  0   0  4
  [13] .ctors            PROGBITS        000014f4 0004f4 000008 00  WA  0   0  4
  [14] .dtors            PROGBITS        000014fc 0004fc 000008 00  WA  0   0  4
  [15] .jcr              PROGBITS        00001504 000504 000004 00  WA  0   0  4
  [16] .dynamic          DYNAMIC         00001508 000508 0000c0 08  WA  3   0  4
  [17] .got              PROGBITS        000015c8 0005c8 00000c 04  WA  0   0  4
  [18] .got.plt          PROGBITS        000015d4 0005d4 000014 04  WA  0   0  4
  [19] .data             PROGBITS        000015e8 0005e8 000008 00  WA  0   0  4
  [20] .bss              NOBITS          000015f0 0005f0 000004 00  WA  0   0  4
  [21] .comment          PROGBITS        00000000 0005f0 00009b 00      0   0  1
  [22] .gnu_debuglink    PROGBITS        00000000 00068b 000010 00      0   0  1
  [23] .shstrtab         STRTAB          00000000 00069b 0000c8 00      0   0  1
  [24] .symtab           SYMTAB          00000000 000b74 000310 10     25  40  4
  [25] .strtab           STRTAB          00000000 000e84 000164 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)



$ readelf -S a.so.debug 
There are 32 section headers, starting at offset 0xa90:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .hash             NOBITS          000000b4 0000b4 000098 00   A  0   0  4
  [ 2] .dynsym           NOBITS          0000014c 0000b4 000130 00   A  0   0  4
  [ 3] .dynstr           NOBITS          0000027c 0000b4 00006f 00   A  0   0  1
  [ 4] .gnu.version      NOBITS          000002ec 0000b4 000026 00   A  0   0  2
  [ 5] .gnu.version_r    NOBITS          00000314 0000b4 000020 00   A  0   0  4
  [ 6] .rel.dyn          NOBITS          00000334 0000b4 000028 00   A  0   0  4
  [ 7] .rel.plt          NOBITS          0000035c 0000b4 000010 00   A  0   0  4
  [ 8] .init             NOBITS          0000036c 0000b4 000017 00  AX  0   0  4
  [ 9] .plt              NOBITS          00000384 0000b4 000030 00  AX  0   0  4
  [10] .text             NOBITS          000003c0 0000b4 000114 00  AX  0   0 16
  [11] .fini             NOBITS          000004d4 0000b4 00001c 00  AX  0   0  4
  [12] .eh_frame         NOBITS          000004f0 0000b4 000004 00   A  0   0  4
  [13] .ctors            NOBITS          000014f4 0004f4 000008 00  WA  0   0  4
  [14] .dtors            NOBITS          000014fc 0004f4 000008 00  WA  0   0  4
  [15] .jcr              NOBITS          00001504 0004f4 000004 00  WA  0   0  4
  [16] .dynamic          NOBITS          00001508 0004f4 0000c0 00  WA  0   0  4
  [17] .got              NOBITS          000015c8 0004f4 00000c 00  WA  0   0  4
  [18] .got.plt          NOBITS          000015d4 0004f4 000014 00  WA  0   0  4
  [19] .data             NOBITS          000015e8 0004f4 000008 00  WA  0   0  4
  [20] .bss              NOBITS          000015f0 0004f4 000004 00  WA  0   0  4
  [21] .comment          PROGBITS        00000000 0004f4 00009b 00      0   0  1
  [22] .debug_aranges    PROGBITS        00000000 000590 000078 00      0   0  8
  [23] .debug_pubnames   PROGBITS        00000000 000608 000018 00      0   0  1
  [24] .debug_info       PROGBITS        00000000 000620 000173 00      0   0  1
  [25] .debug_abbrev     PROGBITS        00000000 000793 000047 00      0   0  1
  [26] .debug_line       PROGBITS        00000000 0007da 000146 00      0   0  1
  [27] .debug_frame      PROGBITS        00000000 000920 00002c 00      0   0  4
  [28] .debug_loc        PROGBITS        00000000 00094c 00002c 00      0   0  1
  [29] .shstrtab         STRTAB          00000000 000978 000116 00      0   0  1
  [30] .symtab           SYMTAB          00000000 000f90 000410 10     31  56  4
  [31] .strtab           STRTAB          00000000 0013a0 0001e4 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


Also, if you look at symfile.c:reread_separate_symbols (before my patch), there was this code:

  /* If the new objfile has separate debug info, and we
     haven't loaded it already, do so now.  */
  if (debug_file
      && ! objfile->separate_debug_objfile)
    {
      /* Use the same section offset table as objfile itself.
         Preserve the flags from objfile that make sense.  */
      objfile->separate_debug_objfile
        = (symbol_file_add_with_addrs_or_offsets
           (symfile_bfd_open (debug_file),
            info_verbose ? SYMFILE_VERBOSE : 0,
            0, /* No addr table.  */
            objfile->section_offsets, objfile->num_sections,
            objfile->flags & (OBJF_REORDERED | OBJF_SHARED | OBJF_READNOW
                              | OBJF_USERLOADED)));
      objfile->separate_debug_objfile->separate_debug_objfile_backlink
        = objfile;
    }

As you can see, I kept this semantic (which might be wrong but this is not my understanding).

BTW, where can I find prelink ?  Looks like it is not available on RHEL S 5.2


> 
> There was some description of these data structures in:
> 	[patch 05/15] PIE: Move some symfile code into subroutines
> 	http://sourceware.org/ml/gdb-patches/2009-11/msg00172.html
> 	[patch 06/15] PIE: Fix displacement of separate debug info files
> 	http://sourceware.org/ml/gdb-patches/2009-11/msg00173.html
> 
> (I see a big conflict now there for my unchecked-in PIE patch, oops.)

Will read these patches.

> One should probably build temporary addr-table from objfile there.

That's a possible solution, but we must first be clear on wether the separate debug file has the same
sections as its binary file.

The main drawback of addr-table is that is it much slower.

Tristan.