From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Jelinek To: binutils@sources.redhat.com, drepper@redhat.com, jason_merrill@redhat.com Subject: Re: RFC: .gnu.linkonce.* and shared libraries Date: Wed, 11 Jul 2001 13:10:00 -0000 Message-id: <20010711161046.P1481@devserv.devel.redhat.com> References: <20010711150723.D899@sunsite.ms.mff.cuni.cz> X-SW-Source: 2001-07/msg00209.html On Wed, Jul 11, 2001 at 12:43:15PM -0700, Ian Lance Taylor wrote: > Jakub Jelinek writes: > > > 3) once all dependent libraries are mapped, if there are any dynamic > > libraries, linker searches all those libraries if it finds an area in the > > corresponding section (.gnu.linkonce.t -> .text etc.) of the library, which: > > > > a) has the required alignment of .gnu.linkonce.* section > > b) all the symbols against the .gnu.linkonce.* section are present there > > too, with the same symbol properties, at the same relative offset > > from start of .gnu.linkonce.* section resp. of the area in the library > > c) likewise for relocations against .gnu.linkonce.* section resp. area, > > again it has to be the same relocation type, same visibility, against > > the same symbol, with the same addend etc. > > d) the content of the .gnu.linkonce.t section is identical to the content > > of the area (for RELA relocations against the area after all > > relocations are relocated to canonical form) > > How does the dynamic linker locate .gnu.linkonce sections? Remember > that the dynamic linker does not look at section headers. It only > looks at program segments. I perhaps have not written it clearly. All of 1)-4) would be done in the static linker, not dynamic linker. Example (using gcc-2.96-RH, but there is nothing different here for gcc 3.0): ld -o kmail ... kbusyptr.o ... -lqt ... kbusyptr.o: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al ... [ 8] .gnu.linkonce.d._ PROGBITS 00000000 000aa0 000040 00 WA 0 0 32 [ 9] .rel.gnu.linkonce REL 00000000 00252c 000040 08 22 8 4 ... Relocation section '.rel.gnu.linkonce.d.__vt_7QBitmap' at offset 0x252c contains 8 entries: Offset Info Type Symbol's Value Symbol's Name 00000004 05401 R_386_32 00000000 __tf7QBitmap 00000008 05501 R_386_32 00000000 _._7QBitmap 0000000c 05601 R_386_32 00000000 setX11Data__12QPaintDevic 00000010 05701 R_386_32 00000000 cmd__12QPaintDeviceiP8QPa 00000014 05801 R_386_32 00000000 metric__C7QPixmapi 00000018 05901 R_386_32 00000000 fontMet__C12QPaintDeviceP 0000001c 05a01 R_386_32 00000000 fontInf__C12QPaintDeviceP 00000020 05b01 R_386_32 00000000 detach__7QPixmap Symbol table '.symtab' contains 112 entries: ... 63: 00000000 40 OBJECT WEAK DEFAULT 8 __vt_7QBitmap ... Contents of section .gnu.linkonce.d.__vt_7QBitmap: 0000 00000000 00000000 00000000 00000000 ................ 0010 00000000 00000000 00000000 00000000 ................ 0020 00000000 00000000 00000000 00000000 ................ 0030 00000000 00000000 00000000 00000000 ................ /usr/lib/qt-2.3.1/lib/libqt.so.2.3.1: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al ... [ 6] .rel.data REL 000ab468 0ab468 02aa08 08 A 2 10 4 ... [16] .data PROGBITS 0049bbe0 49abe0 020660 00 WA 0 0 32 ... Relocation section '.rel.data' at offset 0xab468 contains 21825 entries: Offset Info Type Symbol's Value Symbol's Name ... 004a92b4 14cd01 R_386_32 0014af20 encodedData__C17QClipboar 004a92c4 31aa01 R_386_32 003db550 __tf7QBitmap 004a92c8 98001 R_386_32 003db500 _._7QBitmap 004a92cc c7701 R_386_32 00161f00 setX11Data__12QPaintDevic 004a92d0 128301 R_386_32 00162180 cmd__12QPaintDeviceiP8QPa 004a92d4 149601 R_386_32 0015c400 metric__C7QPixmapi 004a92d8 306b01 R_386_32 001621e0 fontMet__C12QPaintDeviceP 004a92dc 317b01 R_386_32 001621f0 fontInf__C12QPaintDeviceP 004a92e0 f3401 R_386_32 0015c1b0 detach__7QPixmap 004a9304 1cab01 R_386_32 003db640 __tft8QIntDict1Z10QColorD ... Symbol table '.dynsym' contains 12899 entries: ... 8170: 004a92c0 40 OBJECT WEAK DEFAULT 16 __vt_7QBitmap ... Contents of section .data: ... 4a92c0 00000000 00000000 00000000 00000000 ................ 4a92d0 00000000 00000000 00000000 00000000 ................ 4a92e0 00000000 00000000 00000000 00000000 ................ 4a92f0 00000000 00000000 00000000 00000000 ................ (this is about all ld would need to check to find out that it can safely throw away .gnu.linkonce.d.__vt_7QBitmap provided it has: [ 8] .gnu.linkonce.d._ PROGBITS 00000000 000aa0 000040 40 WAM 0 0 32 instead of [ 8] .gnu.linkonce.d._ PROGBITS 00000000 000aa0 000040 00 WA 0 0 32 ). Note that if /usr/lib/qt-2.3.1/lib/libqt.so.2.3.1 was prelinked: a) the relocations would be RELA in .gnu.reloc sections instead and would not be necessarily in the same order as in .rela.gnu.linkonce.d.__vt_7QBitmap - what matters if the relative offsets in r_offset fields are the same b) the content of the area would not necesssarily match the content of the sections in places which have relocations against them - one would need to put r_addends/0 whatever the default state is before comparing them. Jakub