This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RFC: .gnu.linkonce.* and shared libraries


On Wed, Jul 11, 2001 at 12:43:15PM -0700, Ian Lance Taylor wrote:
> Jakub Jelinek <jakub@redhat.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]