Regression on prelinked-sepdebug-shlibs

Regression on prelinked-sepdebug-shlibs

[Jan Kratochvil]

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".

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.)

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

I did not provide the testcase above as a GDB testcase as it is exactly one
case of the more general "break-interp.exp" test supporting shlibs by:
	[patch 10/15] PIE: testcase: Test also shared libraries
	http://sourceware.org/ml/gdb-patches/2009-11/msg00177.html


Regards,
Jan

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

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.

Re: Regression on prelinked-sepdebug-shlibs

[Jan Kratochvil]

On Mon, 04 Jan 2010 10:50:49 +0100, Tristan Gingold wrote:
> 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.

$ rpm -V bash bash-debuginfo; rpm -qf /bin/bash /usr/lib/debug/bin/bash.debug
bash-4.0.35-2.fc12.x86_64
bash-debuginfo-4.0.35-2.fc12.x86_64

/bin/bash:
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000400238 000238 00001c 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            0000000000400254 000254 000020 00   A  0   0  4
  [ 3] .note.gnu.build-id NOTE            0000000000400274 000274 000024 00   A  0   0  4
  [ 4] .gnu.hash         GNU_HASH        0000000000400298 000298 0035a4 00   A  5   0  8
  [ 5] .dynsym           DYNSYM          0000000000403840 003840 00c360 18   A 28   1  8
  [ 6] .gnu.liblist      GNU_LIBLIST     000000000040fba0 00fba0 000050 14   A 28   0  4
  [ 7] .gnu.conflict     RELA            000000000040fbf0 00fbf0 000468 18   A  5   0  8
  [ 8] .gnu.version      VERSYM          0000000000417a2c 017a2c 001048 02   A  5   0  2
  [ 9] .gnu.version_r    VERNEED         0000000000418a78 018a78 000080 00   A 28   2  8
  [10] .rela.dyn         RELA            0000000000418af8 018af8 0000c0 18   A  5   0  8
  [11] .rela.plt         RELA            0000000000418bb8 018bb8 001278 18   A  5  13  8
  [12] .init             PROGBITS        0000000000419e30 019e30 000018 00  AX  0   0  4
  [13] .plt              PROGBITS        0000000000419e48 019e48 000c60 10  AX  0   0  4
  [14] .text             PROGBITS        000000000041aab0 01aab0 0833c8 00  AX  0   0 16
  [15] .fini             PROGBITS        000000000049de78 09de78 00000e 00  AX  0   0  4
  [16] .rodata           PROGBITS        000000000049dea0 09dea0 01bbe8 00   A  0   0 32
  [17] .eh_frame_hdr     PROGBITS        00000000004b9a88 0b9a88 003a4c 00   A  0   0  4
  [18] .eh_frame         PROGBITS        00000000004bd4d8 0bd4d8 0134cc 00   A  0   0  8
  [19] .ctors            PROGBITS        00000000006d09a8 0d09a8 000010 00  WA  0   0  8
  [20] .dtors            PROGBITS        00000000006d09b8 0d09b8 000010 00  WA  0   0  8
  [21] .jcr              PROGBITS        00000000006d09c8 0d09c8 000008 00  WA  0   0  8
  [22] .dynamic          DYNAMIC         00000000006d09d0 0d09d0 0001b0 10  WA 28   0  8
  [23] .got              PROGBITS        00000000006d0b80 0d0b80 000008 08  WA  0   0  8
  [24] .got.plt          PROGBITS        00000000006d0b88 0d0b88 000640 08  WA  0   0  8
  [25] .data             PROGBITS        00000000006d11e0 0d11e0 008364 00  WA  0   0 32
  [26] .dynbss           PROGBITS        00000000006d9560 0d9560 000058 00  WA  0   0 32
  [27] .bss              NOBITS          00000000006d95b8 0d95b8 0057b8 00  WA  0   0 32
  [28] .dynstr           STRTAB          00000000008d95b8 0d95b8 007edf 00   A  0   0  1
  [29] .gnu_debuglink    PROGBITS        0000000000000000 0e1498 000010 00      0   0  4
  [30] .gnu.prelink_undo PROGBITS        0000000000000000 0e14a8 0008c0 01      0   0  8
  [31] .shstrtab         STRTAB          0000000000000000 0e1d68 000129 00      0   0  1

/usr/lib/debug/bin/bash.debug
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           NOBITS          0000000000400200 000200 00001c 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            000000000040021c 000200 000020 00   A  0   0  4
  [ 3] .note.gnu.build-id NOTE            000000000040023c 000220 000024 00   A  0   0  4
  [ 4] .gnu.hash         NOBITS          0000000000400260 000248 0035a4 00   A  5   0  8
  [ 5] .dynsym           NOBITS          0000000000403808 000248 00c360 18   A  6   1  8
  [ 6] .dynstr           NOBITS          000000000040fb68 000248 007ec3 00   A  0   0  1
  [ 7] .gnu.version      NOBITS          0000000000417a2c 000248 001048 02   A  5   0  2
  [ 8] .gnu.version_r    NOBITS          0000000000418a78 000248 000080 00   A  6   2  8
  [ 9] .rela.dyn         NOBITS          0000000000418af8 000248 0000c0 18   A  5   0  8
  [10] .rela.plt         NOBITS          0000000000418bb8 000248 001278 18   A  5  12  8
  [11] .init             NOBITS          0000000000419e30 000248 000018 00  AX  0   0  4
  [12] .plt              NOBITS          0000000000419e48 000248 000c60 10  AX  0   0  4
  [13] .text             NOBITS          000000000041aab0 000250 0833c8 00  AX  0   0 16
  [14] .fini             NOBITS          000000000049de78 000250 00000e 00  AX  0   0  4
  [15] .rodata           NOBITS          000000000049dea0 000260 01bbe8 00   A  0   0 32
  [16] .eh_frame_hdr     NOBITS          00000000004b9a88 000260 003a4c 00   A  0   0  4
  [17] .eh_frame         NOBITS          00000000004bd4d8 000260 0134cc 00   A  0   0  8
  [18] .ctors            NOBITS          00000000006d09a8 000260 000010 00  WA  0   0  8
  [19] .dtors            NOBITS          00000000006d09b8 000260 000010 00  WA  0   0  8
  [20] .jcr              NOBITS          00000000006d09c8 000260 000008 00  WA  0   0  8
  [21] .dynamic          NOBITS          00000000006d09d0 000260 0001b0 10  WA  6   0  8
  [22] .got              NOBITS          00000000006d0b80 000260 000008 08  WA  0   0  8
  [23] .got.plt          NOBITS          00000000006d0b88 000260 000640 08  WA  0   0  8
  [24] .data             NOBITS          00000000006d11e0 000260 008364 00  WA  0   0 32
  [25] .bss              NOBITS          00000000006d9560 000260 005810 00  WA  0   0 32
  [26] .comment          PROGBITS        0000000000000000 000260 001ca7 00      0   0  1
  [27] .debug_aranges    PROGBITS        0000000000000000 001f07 001d10 00      0   0  1
  [28] .debug_pubnames   PROGBITS        0000000000000000 003c17 00a4e6 00      0   0  1
  [29] .debug_info       PROGBITS        0000000000000000 00e0fd 085cf8 00      0   0  1
  [30] .debug_abbrev     PROGBITS        0000000000000000 093df5 01677e 00      0   0  1
  [31] .debug_line       PROGBITS        0000000000000000 0aa573 022fb4 00      0   0  1
  [32] .debug_str        PROGBITS        0000000000000000 0cd527 013a03 01  MS  0   0  1
  [33] .debug_loc        PROGBITS        0000000000000000 0e0f2a 0998d3 00      0   0  1
  [34] .debug_pubtypes   PROGBITS        0000000000000000 17a7fd 00b5b6 00      0   0  1
  [35] .debug_ranges     PROGBITS        0000000000000000 185db3 012850 00      0   0  1
  [36] .shstrtab         STRTAB          0000000000000000 198603 000177 00      0   0  1
  [37] .symtab           SYMTAB          0000000000000000 198780 013d10 18     38 1300  8
  [38] .strtab           STRTAB          0000000000000000 1ac490 00d961 00      0   0  1

This is different after prelink-ing /bin/bash.  After "prelink -u" there are still differences:
(from section 26)
/tmp/bashu:
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000400200 000200 00001c 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            000000000040021c 00021c 000020 00   A  0   0  4
  [ 3] .note.gnu.build-id NOTE            000000000040023c 00023c 000024 00   A  0   0  4
  [ 4] .gnu.hash         GNU_HASH        0000000000400260 000260 0035a4 00   A  5   0  8
  [ 5] .dynsym           DYNSYM          0000000000403808 003808 00c360 18   A  6   1  8
  [ 6] .dynstr           STRTAB          000000000040fb68 00fb68 007ec3 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          0000000000417a2c 017a2c 001048 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         0000000000418a78 018a78 000080 00   A  6   2  8
  [ 9] .rela.dyn         RELA            0000000000418af8 018af8 0000c0 18   A  5   0  8
  [10] .rela.plt         RELA            0000000000418bb8 018bb8 001278 18   A  5  12  8
  [11] .init             PROGBITS        0000000000419e30 019e30 000018 00  AX  0   0  4
  [12] .plt              PROGBITS        0000000000419e48 019e48 000c60 10  AX  0   0  4
  [13] .text             PROGBITS        000000000041aab0 01aab0 0833c8 00  AX  0   0 16
  [14] .fini             PROGBITS        000000000049de78 09de78 00000e 00  AX  0   0  4
  [15] .rodata           PROGBITS        000000000049dea0 09dea0 01bbe8 00   A  0   0 32
  [16] .eh_frame_hdr     PROGBITS        00000000004b9a88 0b9a88 003a4c 00   A  0   0  4
  [17] .eh_frame         PROGBITS        00000000004bd4d8 0bd4d8 0134cc 00   A  0   0  8
  [18] .ctors            PROGBITS        00000000006d09a8 0d09a8 000010 00  WA  0   0  8
  [19] .dtors            PROGBITS        00000000006d09b8 0d09b8 000010 00  WA  0   0  8
  [20] .jcr              PROGBITS        00000000006d09c8 0d09c8 000008 00  WA  0   0  8
  [21] .dynamic          DYNAMIC         00000000006d09d0 0d09d0 0001b0 10  WA  6   0  8
  [22] .got              PROGBITS        00000000006d0b80 0d0b80 000008 08  WA  0   0  8
  [23] .got.plt          PROGBITS        00000000006d0b88 0d0b88 000640 08  WA  0   0  8
  [24] .data             PROGBITS        00000000006d11e0 0d11e0 008364 00  WA  0   0 32
  [25] .bss              NOBITS          00000000006d9560 0d9544 005810 00  WA  0   0 32
  [26] .gnu_debuglink    PROGBITS        0000000000000000 0d9544 000010 00      0   0  4
  [27] .shstrtab         STRTAB          0000000000000000 0d9554 0000f4 00      0   0  1


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

OK, so reread_separate_symbols was wrong.  This rereading code needs
a rewrite - to unify it with the common loading code.


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

It has been always provided in RHELs, Fedoras etc.:
ftp://ftp.redhat.com/redhat/linux/enterprise/5Server/en/os/SRPMS/prelink-0.3.9-2.1.src.rpm


> > 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.

I meant rather just the initial comments, not the patches themselves.


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

IMO this kind of performance difference is negligible to be considered.
It is some overhead per-section while now GDB has many overheads per-symbol.


Regards,
Jan

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

On Jan 4, 2010, at 11:23 AM, Jan Kratochvil wrote:

> On Mon, 04 Jan 2010 10:50:49 +0100, Tristan Gingold wrote:
>> 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.
> 
> $ rpm -V bash bash-debuginfo; rpm -qf /bin/bash /usr/lib/debug/bin/bash.debug
> bash-4.0.35-2.fc12.x86_64
> bash-debuginfo-4.0.35-2.fc12.x86_64

[...]

Ok, looks like we can't assume that they have identical sections: objcopy looks unable to keep
ELF specific sections.

> 
>> Also, if you look at symfile.c:reread_separate_symbols (before my patch),
>> there was this code:
> 
> OK, so reread_separate_symbols was wrong.  This rereading code needs
> a rewrite - to unify it with the common loading code.

Unification is already done (was part of my patch).

>> BTW, where can I find prelink ?  Looks like it is not available on RHEL S 5.2
> 
> It has been always provided in RHELs, Fedoras etc.:

Thanks.  /usr/sbin was not in my path.

>> The main drawback of addr-table is that is it much slower.
> 
> IMO this kind of performance difference is negligible to be considered.
> It is some overhead per-section while now GDB has many overheads per-symbol.

Ok, maybe we can use addr-table instead.  I am not a big fan of this approach but we may improve this later.

Thanks,
Tristan.

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

Jan,

can you try and/or comment this patch before I officially submit it ?  No sepdebug.exp regressions.

Tristan.


2010-01-04  Tristan Gingold  <gingold@adacore.com>

	* symfile.c (build_section_addr_info_from_objfile): New function.
	(symbol_file_add_separate): Don't use offsets from objfile but
	built an addr info.

diff --git a/gdb/symfile.c b/gdb/symfile.c
index 11bc2af..d6ecf0d 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -384,6 +384,38 @@ build_section_addr_info_from_section_table (const struct target_section *start,
   return sap;
 }
 
+/* Create a section_addr_info from section offsets in OBJFILE.  Return NULL
+   if all offsets are 0.  */
+
+static struct section_addr_info *
+build_section_addr_info_from_objfile (const struct objfile *objfile)
+{
+  struct section_addr_info *sap;
+  int i;
+  struct bfd_section *sec;
+
+  /* In most cases, the offsets are 0.  In this case we return NULL to reduce
+     overhead.  */
+  for (i = 0; i < objfile->num_sections; i++)
+    if (objfile->section_offsets->offsets[i])
+      break;
+  if (i >= objfile->num_sections)
+    return NULL;
+
+  sap = alloc_section_addr_info (objfile->num_sections);
+  for (i = 0, sec = objfile->obfd->sections;
+       i < objfile->num_sections;
+       i++, sec = sec->next)
+    {
+      gdb_assert (sec != NULL);
+      sap->other[i].addr = bfd_get_section_vma (objfile->obfd, sec)
+        + objfile->section_offsets->offsets[i];
+      sap->other[i].name = xstrdup (bfd_get_section_name (objfile->obfd, sec));
+      sap->other[i].sectindex = sec->index;
+    }
+  return sap;
+}
+
 
 /* Free all memory allocated by build_section_addr_info_from_section_table. */
 
@@ -1042,16 +1074,26 @@ symbol_file_add_with_addrs_or_offsets (bfd *abfd,
 void
 symbol_file_add_separate (bfd *bfd, int symfile_flags, struct objfile *objfile)
 {
+  struct section_addr_info *sap;
+  struct cleanup *my_cleanup;
+
   /* Currently only one separate debug objfile is supported.  */
   gdb_assert (objfile && objfile->separate_debug_objfile == NULL);
 
+  sap = build_section_addr_info_from_objfile (objfile);
+  if (sap)
+    my_cleanup = make_cleanup_free_section_addr_info (sap);
+
   objfile->separate_debug_objfile =
     symbol_file_add_with_addrs_or_offsets
     (bfd, symfile_flags,
-     0, /* No addr table.  */
-     objfile->section_offsets, objfile->num_sections,
+     sap, NULL, 0,
      objfile->flags & (OBJF_REORDERED | OBJF_SHARED | OBJF_READNOW
 		       | OBJF_USERLOADED));
+
+  if (sap)
+    do_cleanups (my_cleanup);
+
   objfile->separate_debug_objfile->separate_debug_objfile_backlink
     = objfile;

Re: Regression on prelinked-sepdebug-shlibs

[Jan Kratochvil]

Hi Tristan,

On Mon, 04 Jan 2010 16:23:22 +0100, Tristan Gingold wrote:
> can you try and/or comment this patch before I officially submit it ?  No sepdebug.exp regressions.

it works (for the reproducer I provided - you could not run it?) after
removing:

+  /* In most cases, the offsets are 0.  In this case we return NULL to reduce
+     overhead.  */
+  for (i = 0; i < objfile->num_sections; i++)
+    if (objfile->section_offsets->offsets[i])
+      break;
+  if (i >= objfile->num_sections)
+    return NULL;

These offsets are for file vs. memory displacement.  If I have .so prelinked at
0x3404200190 it gets loaded at 0x3404200190 so
objfile->section_offsets->offsets[*] will be 0 but still the .so.debug file is
0x0-based and the .so.debug file needs to be relocated to 0x3404200190.


Thanks,
Jan

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

On Jan 4, 2010, at 7:10 PM, Jan Kratochvil wrote:

Hi Jan,

> On Mon, 04 Jan 2010 16:23:22 +0100, Tristan Gingold wrote:
>> can you try and/or comment this patch before I officially submit it ?  No sepdebug.exp regressions.
> 
> it works (for the reproducer I provided - you could not run it?)

In fact not easily.  The RH machine on which I can run this test hasn't access to my home and I haven't
taken the time to put a new gdb repo.

> after
> removing:
> 
> +  /* In most cases, the offsets are 0.  In this case we return NULL to reduce
> +     overhead.  */
> +  for (i = 0; i < objfile->num_sections; i++)
> +    if (objfile->section_offsets->offsets[i])
> +      break;
> +  if (i >= objfile->num_sections)
> +    return NULL;
> 
> These offsets are for file vs. memory displacement.  If I have .so prelinked at
> 0x3404200190 it gets loaded at 0x3404200190 so
> objfile->section_offsets->offsets[*] will be 0 but still the .so.debug file is
> 0x0-based and the .so.debug file needs to be relocated to 0x3404200190.

Yes, that's right.

But without that sepdebug.exp fails: by default (default_symfile_offsets), addresses from addr_info are
used as offsets.  So if I put the vma into address, the addresses of the separate debug file are doubled.
The convertion of addr to offset in syms_from_objfile is *not* done for mainline sym files - but I don't
know why.

Unless I still don't understand something it looks like we need to coordinate to submit this patch.
IIUC you haven't yet committed all your PIE patches.  Could you simply add it to your own patches set ?

Tristan.

Re: Regression on prelinked-sepdebug-shlibs

[Jan Kratochvil]

On Tue, 05 Jan 2010 12:02:46 +0100, Tristan Gingold wrote:
> But without that sepdebug.exp fails: by default (default_symfile_offsets),
> addresses from addr_info are used as offsets.  So if I put the vma into
> address, the addresses of the separate debug file are doubled.  The
> convertion of addr to offset in syms_from_objfile is *not* done for mainline
> sym files - but I don't know why.

I also do not know why but fixed it now:
	http://sourceware.org/ml/gdb-patches/2010-01/msg00080.html
	http://sourceware.org/ml/gdb-cvs/2010-01/msg00039.html


> Unless I still don't understand something it looks like we need to
> coordinate to submit this patch.  IIUC you haven't yet committed all your
> PIE patches.  Could you simply add it to your own patches set ?

I will have to rebase the PIE patchset.  I see I created a lot of needless
rebasing by not checking-in the parts approved that time (and at least those
just moving the code around).


Regards,
Jan

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

On Jan 5, 2010, at 5:14 PM, Jan Kratochvil wrote:

> On Tue, 05 Jan 2010 12:02:46 +0100, Tristan Gingold wrote:
>> But without that sepdebug.exp fails: by default (default_symfile_offsets),
>> addresses from addr_info are used as offsets.  So if I put the vma into
>> address, the addresses of the separate debug file are doubled.  The
>> convertion of addr to offset in syms_from_objfile is *not* done for mainline
>> sym files - but I don't know why.
> 
> I also do not know why but fixed it now:
> 	http://sourceware.org/ml/gdb-patches/2010-01/msg00080.html
> 	http://sourceware.org/ml/gdb-cvs/2010-01/msg00039.html

Thanks.

I have just submitted the patch to fix the regression.

Tristan.

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

Jan,

do you have a patch for dwarf2read.c(dwarf2_psymtab_to_symtab) ?

	  /* If this psymtab is constructed from a debug-only objfile, the
	     has_section_at_zero flag will not necessarily be correct.  We
	     can get the correct value for this flag by looking at the data
	     associated with the (presumably stripped) associated objfile.  */
	  if (pst->objfile->separate_debug_objfile_backlink)
	    {
	      struct dwarf2_per_objfile *dpo_backlink
	        = objfile_data (pst->objfile->separate_debug_objfile_backlink,
		                dwarf2_objfile_data_key);
	      dwarf2_per_objfile->has_section_at_zero
		= dpo_backlink->has_section_at_zero;
	    }

I think this is not correct: the separate debug file may have one section at zero while the main may not.
In the above code, we do not consider wether an offset is used.

I am not sure that this can happen with ELF however.

Tristan.

Re: Regression on prelinked-sepdebug-shlibs

[Jan Kratochvil]

Hi Tristan,

On Wed, 06 Jan 2010 17:38:55 +0100, Tristan Gingold wrote:
> do you have a patch for dwarf2read.c(dwarf2_psymtab_to_symtab) ?
> 
> 	  /* If this psymtab is constructed from a debug-only objfile, the
> 	     has_section_at_zero flag will not necessarily be correct.  We
> 	     can get the correct value for this flag by looking at the data
> 	     associated with the (presumably stripped) associated objfile.  */
> 	  if (pst->objfile->separate_debug_objfile_backlink)
> 	    {
> 	      struct dwarf2_per_objfile *dpo_backlink
> 	        = objfile_data (pst->objfile->separate_debug_objfile_backlink,
> 		                dwarf2_objfile_data_key);
> 	      dwarf2_per_objfile->has_section_at_zero
> 		= dpo_backlink->has_section_at_zero;
> 	    }
> 
> I think this is not correct: the separate debug file may have one section at
> zero while the main may not.  In the above code, we do not consider wether
> an offset is used.
> 
> I am not sure that this can happen with ELF however.

This has_section_at_zero feature is intended for embedded targets.  I only
know has_section_at_zero can never happen for cases I am aware of.

IMHO embedded targets do not use the file-vs-memory offsets but not sure.
Also the embedded targets probably do not use .linkonce/COMDAT - this is why
this has_section_at_zero differentiator could work.

[PATCH] Allow dwarf2 debug info for function at address 0
http://sourceware.org/ml/gdb-patches/2006-07/msg00291.html


Regards,
Jan

Re: Regression on prelinked-sepdebug-shlibs

[Daniel Jacobowitz]

On Wed, Jan 06, 2010 at 07:05:10PM +0100, Jan Kratochvil wrote:
> On Wed, 06 Jan 2010 17:38:55 +0100, Tristan Gingold wrote:
> > I think this is not correct: the separate debug file may have one section at
> > zero while the main may not.  In the above code, we do not consider wether
> > an offset is used.
> > 
> > I am not sure that this can happen with ELF however.

Sorry, I don't quite understand this.

> This has_section_at_zero feature is intended for embedded targets.  I only
> know has_section_at_zero can never happen for cases I am aware of.
> 
> IMHO embedded targets do not use the file-vs-memory offsets but not sure.
> Also the embedded targets probably do not use .linkonce/COMDAT - this is why
> this has_section_at_zero differentiator could work.

An embedded program can use either of these things.  The
linkonce/comdat issue is a constant problem, but this was the best
available heuristic.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

On Jan 6, 2010, at 8:16 PM, Daniel Jacobowitz wrote:

> On Wed, Jan 06, 2010 at 07:05:10PM +0100, Jan Kratochvil wrote:
>> On Wed, 06 Jan 2010 17:38:55 +0100, Tristan Gingold wrote:
>>> I think this is not correct: the separate debug file may have one section at
>>> zero while the main may not.  In the above code, we do not consider wether
>>> an offset is used.
>>> 
>>> I am not sure that this can happen with ELF however.
> 
> Sorry, I don't quite understand this.

I am not sure that you can create a linux native executable with a section whose vma is 0.

I tried this:
$ cat sep.c
#include <stdio.h>

int zero (void) __attribute__((section("sec_zero")));
int zero (void)
{
  return 0;
}

int main (void)
{
  printf ("Zero=%d\n", zero ());
  return 0;
}

$ gcc -c -g sep.c
$ gcc -o sep sep.o -Wl,--section-start,sec_zero=0

But unfortunately linux refuses to execute that (I got a sigkill very very early) so I can't play with that.
(and I haven't investigated further in the kernel ;-)

>> This has_section_at_zero feature is intended for embedded targets.  I only
>> know has_section_at_zero can never happen for cases I am aware of.
>> 
>> IMHO embedded targets do not use the file-vs-memory offsets but not sure.
>> Also the embedded targets probably do not use .linkonce/COMDAT - this is why
>> this has_section_at_zero differentiator could work.
> 
> An embedded program can use either of these things.  The
> linkonce/comdat issue is a constant problem, but this was the best
> available heuristic.

I agree that this heuristic make sense.  However I don't think that the one used for separate debug objfile
is correct.  I will submit a patch to discuss this point.

Tristan.

Re: Regression on prelinked-sepdebug-shlibs

[Jan Kratochvil]

On Thu, 07 Jan 2010 12:03:04 +0100, Tristan Gingold wrote:
...
> I am not sure that you can create a linux native executable with a section whose vma is 0.
> But unfortunately linux refuses to execute that (I got a sigkill very very
> early) so I can't play with that.

https://bugzilla.redhat.com/show_bug.cgi?id=434714

From Chuck Ebbert:
echo "0" >/proc/sys/vm/mmap_min_addr
That should fix it -- at least on F8 changing that from 0 to 32768 made it fail.
(The executable code starts at 0.)

From Roland McGrath:
Yup, I think this is pretty much expected behavior.
i.e. an ET_EXEC with a p_vaddr at 0 is asking for a mmap that it is often
security policy to refuse.  Unfortunately there really isn't much better than
SIGKILL death that you can expect for this.



Regards,
Jan

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

On Jan 7, 2010, at 12:09 PM, Jan Kratochvil wrote:

> On Thu, 07 Jan 2010 12:03:04 +0100, Tristan Gingold wrote:
> ...
>> I am not sure that you can create a linux native executable with a section whose vma is 0.
>> But unfortunately linux refuses to execute that (I got a sigkill very very
>> early) so I can't play with that.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=434714
> 
> From Chuck Ebbert:
> echo "0" >/proc/sys/vm/mmap_min_addr
> That should fix it -- at least on F8 changing that from 0 to 32768 made it fail.
> (The executable code starts at 0.)
> 
> From Roland McGrath:
> Yup, I think this is pretty much expected behavior.
> i.e. an ET_EXEC with a p_vaddr at 0 is asking for a mmap that it is often
> security policy to refuse.  Unfortunately there really isn't much better than
> SIGKILL death that you can expect for this.

Ah, ah, you already tried that!

Unfortunately I am not root on these linux machine.  However, I can execute it with qemu.  So I can now play.

Thanks,
Tristan.

Re: Regression on prelinked-sepdebug-shlibs

[Daniel Jacobowitz]

On Thu, Jan 07, 2010 at 12:03:04PM +0100, Tristan Gingold wrote:
> I am not sure that you can create a linux native executable with a section whose vma is 0.

I'm pretty sure you can't.  The program headers are going to be at the
start of the executable, before any section.  So I'm not entirely sure
what kind of executable you get from doing this :-)

It's different if you use an embedded target, because ELF headers
aren't typically mapped or loaded into memory.


-- 
Daniel Jacobowitz
CodeSourcery

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

On Jan 7, 2010, at 2:42 PM, Daniel Jacobowitz wrote:

> On Thu, Jan 07, 2010 at 12:03:04PM +0100, Tristan Gingold wrote:
>> I am not sure that you can create a linux native executable with a section whose vma is 0.
> 
> I'm pretty sure you can't.  The program headers are going to be at the
> start of the executable, before any section.  So I'm not entirely sure
> what kind of executable you get from doing this :-)

You lost me.  They can be on different pages ?

In fact I can build such a statically linked program.  However it looks like ld.so or libc doesn't like
such a program (also it is buildable).

$ cat sep.c
int zero (void) __attribute__((section("sec_zero")));
int zero (void)
{
  return 12;
}

void _start (void)
{
  asm volatile ("int $0x80" : : "a"(1), "b"(zero()));
}

$ gcc -c -g -m32 sep.c
$ gcc -m32 -o sep sep.o -Wl,--section-start,sec_zero=0 -nostdlib
$ readelf -S sep
There are 14 section headers, starting at offset 0x136c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] sec_zero          PROGBITS        00000000 001000 00000a 00  AX  0   0  1
  [ 2] .text             PROGBITS        08048094 001094 000015 00  AX  0   0  4
  [ 3] .comment          PROGBITS        00000000 0010a9 00002e 00      0   0  1
  [ 4] .debug_aranges    PROGBITS        00000000 0010d7 000028 00      0   0  1
  [ 5] .debug_pubnames   PROGBITS        00000000 0010ff 000026 00      0   0  1
  [ 6] .debug_info       PROGBITS        00000000 001125 00008c 00      0   0  1
  [ 7] .debug_abbrev     PROGBITS        00000000 0011b1 000047 00      0   0  1
  [ 8] .debug_line       PROGBITS        00000000 0011f8 000044 00      0   0  1
  [ 9] .debug_frame      PROGBITS        00000000 00123c 000048 00      0   0  4
  [10] .debug_loc        PROGBITS        00000000 001284 000058 00      0   0  1
  [11] .shstrtab         STRTAB          00000000 0012dc 000090 00      0   0  1
  [12] .symtab           SYMTAB          00000000 00159c 000110 10     13  12  4
  [13] .strtab           STRTAB          00000000 0016ac 00002b 00      0   0  1

Tristan.

Re: Regression on prelinked-sepdebug-shlibs

[Daniel Jacobowitz]

On Thu, Jan 07, 2010 at 03:22:21PM +0100, Tristan Gingold wrote:
> $ readelf -S sep
> There are 14 section headers, starting at offset 0x136c:
> 
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
>   [ 1] sec_zero          PROGBITS        00000000 001000 00000a 00  AX  0   0  1

Notice the non-zero offset.

% readelf -l sep

Elf file type is EXEC (Executable file)
Entry point 0x80480f8
There are 5 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00000000 0x00000000 0x0000a 0x0000a R E 0x1000
  LOAD           0x0010d4 0x080480d4 0x080480d4 0x00039 0x00039 R E 0x1000

The file offset 0 is not mapped.  That means the program headers, at
offset 52, are not mapped.  So ld.so can't find them.

I'm surprised the static executable worked, but I can see how that
might happen.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Regression on prelinked-sepdebug-shlibs

[Tristan Gingold]

On Jan 7, 2010, at 3:25 PM, Daniel Jacobowitz wrote:
> 
> The file offset 0 is not mapped.  That means the program headers, at
> offset 52, are not mapped.  So ld.so can't find them.

I understand what you mean.  Thanks.

Tristan.