This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Question on symbol versioning
"Amker.Cheng" <amker.cheng@gmail.com> writes:
>> The base version definition in an executable or shared library is the
>> one with VER_FLG_BASE set in the vd_flags field of a Verdef structure in
>> the SHT_GNU_verdef section aka the data to which DT_VERDEF/DT_VERDEFNUM
>> dynamic tags point. ÂVER_FLG_BASE has the value 1. ÂThere is a bit of
>> documentation at
>> http://docs.sun.com/app/docs/doc/819-0690/chapter6-93046?l=en&a=view .
>
> Thanks, but still could not get it. I dumped version info of eglibc's
> libc.so.6 for mips,
> the first three entries of section ".gnu_version_d" are like:
>
> Version definition section '.gnu.version_d' contains 19 entries:
> Addr: 0x0000000000012644 Offset: 0x012644 Link: 6 (.dynstr)
> 000000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: libc.so.6
> <-------------flag BASE
> 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GLIBC_2.0
> 0x0038: Rev: 1 Flags: none Index: 3 Cnt: 2 Name: GLIBC_2.2
> 0x0054: Parent 1: GLIBC_2.0
>
> While other entries are in forms like GLIBC_2.*, why does the base one
> have name "libc.so.6",
> which is the libc file's name?
It's just convention. The other names come from the version script or
from the versions attached to the symbol names. There is no particular
name to associate with the base version, so the linker uses SONAME or
the name of the output flie.
> further more, considering a little example, test.c
> like
>
> #include "stdio.h"
> FILE * func(int fd)
> {
> return fdopen(fd, "a+w");
> }
>
> then generating test.so with commands:
>
> mipsel-linux-gnu-gcc -fPIC -c -O2 test.c -o test.o
> mipsel-linux-gnu-ld -shared test.o -o test.so
>
> dumping dynamic symbol table with readelf -s:
>
> Symbol table '.dynsym' contains 13 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 00000000 0 NOTYPE LOCAL DEFAULT UND
> ......
> 12: 00000320 0 FUNC GLOBAL DEFAULT UND fdopen
>
> it's clear test.so references fdopen without versioning information.
> when try running test.so on my linux system, the call to fdopen is bound
> to fdopen@GLIBC_2.0 , not the latest version fdopen@GLIBC_2.2,
> by dynamic linker
What does readelf -V print for your executable?
Ian