* identifying symbol versions available to dlvsym
@ 2007-12-03 17:48 Manuel Arriaga
2007-12-03 18:14 ` Manuel Arriaga
0 siblings, 1 reply; 5+ messages in thread
From: Manuel Arriaga @ 2007-12-03 17:48 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: identifying symbol versions available to dlvsym
2007-12-03 17:48 identifying symbol versions available to dlvsym Manuel Arriaga
@ 2007-12-03 18:14 ` Manuel Arriaga
2007-12-21 16:23 ` Nick Clifton
0 siblings, 1 reply; 5+ messages in thread
From: Manuel Arriaga @ 2007-12-03 18:14 UTC (permalink / raw)
To: binutils
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: identifying symbol versions available to dlvsym
2007-12-03 18:14 ` Manuel Arriaga
@ 2007-12-21 16:23 ` Nick Clifton
2007-12-21 16:27 ` Jakub Jelinek
0 siblings, 1 reply; 5+ messages in thread
From: Nick Clifton @ 2007-12-21 16:23 UTC (permalink / raw)
To: Manuel Arriaga; +Cc: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: identifying symbol versions available to dlvsym
2007-12-21 16:23 ` Nick Clifton
@ 2007-12-21 16:27 ` Jakub Jelinek
2007-12-22 17:09 ` Manuel Arriaga
0 siblings, 1 reply; 5+ messages in thread
From: Jakub Jelinek @ 2007-12-21 16:27 UTC (permalink / raw)
To: Nick Clifton; +Cc: Manuel Arriaga, binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: identifying symbol versions available to dlvsym
2007-12-21 16:27 ` Jakub Jelinek
@ 2007-12-22 17:09 ` Manuel Arriaga
0 siblings, 0 replies; 5+ messages in thread
From: Manuel Arriaga @ 2007-12-22 17:09 UTC (permalink / raw)
To: Jakub Jelinek, Nick Clifton, binutils
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-12-22 17:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-03 17:48 identifying symbol versions available to dlvsym Manuel Arriaga
2007-12-03 18:14 ` Manuel Arriaga
2007-12-21 16:23 ` Nick Clifton
2007-12-21 16:27 ` Jakub Jelinek
2007-12-22 17:09 ` Manuel Arriaga
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).