identifying symbol versions available to dlvsym

identifying symbol versions available to dlvsym

[Manuel Arriaga]

Hello everyone,

I am trying to determine which versions of a given symbol (in this
case, fopen) are available in a system's GNU libc for loading through
dlvsym().  How can I do that?

I thought I could get this from objdump


$ objdump -T /lib/libc-2.6.1.so |grep " fopen$"
000575f0 g    DF .text  00000032  GLIBC_2.1   fopen
000f9380 g    DF .text  00000097 (GLIBC_2.0)  fopen


but then I tried running the attached program on the two versions
listed for fopen (GLIBC_2.0 and GLIBC_2.1) and it failed

$ ./dlvsym fopen GLIBC_2.1
fp= 0
dlerror()==NULL
$ ./dlvsym fopen GLIBC_2.0
fp= 0
dlerror()==NULL

Through "brute-force"ing version numbers, I identified the version
GLIBC_2.2.5 as available on this system:

$ ./dlvsym fopen GLIBC_2.2.5
fp= 1772397760
dlerror()==NULL

But then I have another system with an earlier GNU libc version
(2.3.5) in which objdump lists the same symbol versions yet I can only
load fopen version GLIBC_2.1 using dlvsym.

What is the correct way to identify which versions of a given function
I can load with dlvsym?

Thank you for any help

Manuel

Re: identifying symbol versions available to dlvsym

[Manuel Arriaga]

OK, so some experimentation and additional searching showed me that
GNU libc's fopen does not necessarily reside on /lib/libc.so.6. By
looking into a different shared lib, one reads

$ readelf -s /lib64/libc.so.6 |grep " fopen@"
   162: 000000000005f4c0    10 FUNC    GLOBAL DEFAULT   12 fopen@@GLIBC_2.2.5

which is precisely the version number that works with dlvsym().

How could I have found this programatically? To identify the version
of fopen being used, can I do better than

1) running ldd on an executable containing a call to fopen();
2) run readelf -s | grep fopen on each of the libs listed; and
3) using the first version string I find in 2) in my calls to dlvsym?

Thank you for any help,

Cheers

Manuel




On Dec 3, 2007 12:48 PM, Manuel Arriaga <manuelarriaga1980@gmail.com> wrote:
> Hello everyone,
>
> I am trying to determine which versions of a given symbol (in this
> case, fopen) are available in a system's GNU libc for loading through
> dlvsym().  How can I do that?
>
> I thought I could get this from objdump
>
>
> $ objdump -T /lib/libc-2.6.1.so |grep " fopen$"
> 000575f0 g    DF .text  00000032  GLIBC_2.1   fopen
> 000f9380 g    DF .text  00000097 (GLIBC_2.0)  fopen
>
>
> but then I tried running the attached program on the two versions
> listed for fopen (GLIBC_2.0 and GLIBC_2.1) and it failed
>
> $ ./dlvsym fopen GLIBC_2.1
> fp= 0
> dlerror()==NULL
> $ ./dlvsym fopen GLIBC_2.0
> fp= 0
> dlerror()==NULL
>
> Through "brute-force"ing version numbers, I identified the version
> GLIBC_2.2.5 as available on this system:
>
> $ ./dlvsym fopen GLIBC_2.2.5
> fp= 1772397760
> dlerror()==NULL
>
> But then I have another system with an earlier GNU libc version
> (2.3.5) in which objdump lists the same symbol versions yet I can only
> load fopen version GLIBC_2.1 using dlvsym.
>
> What is the correct way to identify which versions of a given function
> I can load with dlvsym?
>
> Thank you for any help
>
> Manuel
>

Re: identifying symbol versions available to dlvsym

[Nick Clifton]

Hi Manuel,

   I am sorry that it has taken so long for us to reply to your posts.

> OK, so some experimentation and additional searching showed me that
> GNU libc's fopen does not necessarily reside on /lib/libc.so.6. By
> looking into a different shared lib, one reads
> 
> $ readelf -s /lib64/libc.so.6 |grep " fopen@"
>    162: 000000000005f4c0    10 FUNC    GLOBAL DEFAULT   12 fopen@@GLIBC_2.2.5
> 
> which is precisely the version number that works with dlvsym().
> 
> How could I have found this programatically? To identify the version
> of fopen being used, can I do better than
> 
> 1) running ldd on an executable containing a call to fopen();
> 2) run readelf -s | grep fopen on each of the libs listed; and
> 3) using the first version string I find in 2) in my calls to dlvsym?

Essentially this is actually the best method.  The problem is that the version 
of fopen used will depend a lot upon the binary containing the invocation.  As 
you have seen 64-bit and 32-bit binaries will use different versions.  Plus 
there is the library load path to consider, plus any paths encoded in the 
actual binary and so on.  Running ldd resolves most of these problems to give 
you a list of the actual libraries that will be used (modulo following sym 
links of course) and then you need to use readelf or objdump to find the 
version symbol, just as you have done.

Cheers
   Nick

Re: identifying symbol versions available to dlvsym

[Jakub Jelinek]

On Fri, Dec 21, 2007 at 04:22:41PM +0000, Nick Clifton wrote:
>   I am sorry that it has taken so long for us to reply to your posts.
> 
> >OK, so some experimentation and additional searching showed me that
> >GNU libc's fopen does not necessarily reside on /lib/libc.so.6. By
> >looking into a different shared lib, one reads
> >
> >$ readelf -s /lib64/libc.so.6 |grep " fopen@"
> >   162: 000000000005f4c0    10 FUNC    GLOBAL DEFAULT   12 
> >   fopen@@GLIBC_2.2.5
> >
> >which is precisely the version number that works with dlvsym().
> >
> >How could I have found this programatically? To identify the version
> >of fopen being used, can I do better than
> >
> >1) running ldd on an executable containing a call to fopen();
> >2) run readelf -s | grep fopen on each of the libs listed; and
> >3) using the first version string I find in 2) in my calls to dlvsym?

Well, usually you don't want the first version, but the default version (the
one with @@ instead of just @), because that matches the headers of the
library and what you'd normally get if you directly linked against the
library rather than using dlvsym.

	Jakub

Re: identifying symbol versions available to dlvsym

[Manuel Arriaga]

Nick, Jakub: Thank you for your help! I will update libtrash to use
the @@ version instead of the first one listed.

All the best

Manuel



On Dec 21, 2007 11:33 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Dec 21, 2007 at 04:22:41PM +0000, Nick Clifton wrote:
> >   I am sorry that it has taken so long for us to reply to your posts.
> >
> > >OK, so some experimentation and additional searching showed me that
> > >GNU libc's fopen does not necessarily reside on /lib/libc.so.6. By
> > >looking into a different shared lib, one reads
> > >
> > >$ readelf -s /lib64/libc.so.6 |grep " fopen@"
> > >   162: 000000000005f4c0    10 FUNC    GLOBAL DEFAULT   12
> > >   fopen@@GLIBC_2.2.5
> > >
> > >which is precisely the version number that works with dlvsym().
> > >
> > >How could I have found this programatically? To identify the version
> > >of fopen being used, can I do better than
> > >
> > >1) running ldd on an executable containing a call to fopen();
> > >2) run readelf -s | grep fopen on each of the libs listed; and
> > >3) using the first version string I find in 2) in my calls to dlvsym?
>
> Well, usually you don't want the first version, but the default version (the
> one with @@ instead of just @), because that matches the headers of the
> library and what you'd normally get if you directly linked against the
> library rather than using dlvsym.
>
>         Jakub
>