* Use of readelf -D option
@ 2007-04-11 1:11 David Arnold
2007-04-14 1:27 ` Jim Wilson
0 siblings, 1 reply; 5+ messages in thread
From: David Arnold @ 2007-04-11 1:11 UTC (permalink / raw)
To: binutils; +Cc: david
hi,
in porting some testsuite code to RHEL5/x86_64, i've run into a problem
with readelf. the code runs readelf against our built shared libs,
extracts a list of the visible global symbols, and checks that there's a
suitable man page for each (with a list of known exceptions).
on other systems (eg binutils 2.17 on Debian/unstable i386 and binutils
2.15.92.0.2 on RHEL4/x86_64), readelf -sD appears to list the .dynsym
symbol table only. but on RHEL5/x86_64, it produces:
# readelf -sD lib/.libs/libelvin.so.4.1.9
Dynamic symbol information is not available for displaying symbols.
#
i haven't been able to find an explanation of the change in behaviour:
can anyone enlighten me?
thanks muchly,
d
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Use of readelf -D option
2007-04-11 1:11 Use of readelf -D option David Arnold
@ 2007-04-14 1:27 ` Jim Wilson
2007-04-15 4:59 ` David Arnold
0 siblings, 1 reply; 5+ messages in thread
From: Jim Wilson @ 2007-04-14 1:27 UTC (permalink / raw)
To: David Arnold; +Cc: binutils
On Wed, 2007-04-11 at 11:10 +1000, David Arnold wrote:
> # readelf -sD lib/.libs/libelvin.so.4.1.9
> Dynamic symbol information is not available for displaying symbols.
Just taking a quick look at the FSF readelf sources, it appears that you
will get this message if there is no .dynamic section, or if DT_HASH is
missing in the dynamic section. That implies that either you don't have
a shared library, or it is corrupted.
readelf -d will show the .dynamic section if there is one. There should
be a symbol HASH inside it.
You can try checking to see if an FSF binutils release works. I don't
have access to RHEL5, so I can't comment further on that.
If this doesn't help, then we will likely need a testcase that we can
use to reproduce the problem. Or you could try debugging readelf to see
what is going on.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Use of readelf -D option
2007-04-14 1:27 ` Jim Wilson
@ 2007-04-15 4:59 ` David Arnold
2007-04-15 7:48 ` H. J. Lu
2007-04-21 19:50 ` Jim Wilson
0 siblings, 2 replies; 5+ messages in thread
From: David Arnold @ 2007-04-15 4:59 UTC (permalink / raw)
To: Jim Wilson; +Cc: binutils
-->"Jim" == Jim Wilson <wilson@specifix.com> writes:
Jim> On Wed, 2007-04-11 at 11:10 +1000, David Arnold wrote:
>> # readelf -sD lib/.libs/libelvin.so.4.1.9 Dynamic symbol
>> information is not available for displaying symbols.
Jim> Just taking a quick look at the FSF readelf sources, it appears
Jim> that you will get this message if there is no .dynamic section,
Jim> or if DT_HASH is missing in the dynamic section. That implies
Jim> that either you don't have a shared library, or it is corrupted.
am i correct in remembering that on x86_64 and with recent binutils,
there's only a DT_GNU_HASH?
Jim> readelf -d will show the .dynamic section if there is one. There
Jim> should be a symbol HASH inside it.
in this case (RHEL5, binutils 2.17.50.0.6-2.el5 20061020), there's only
a GNU_HASH (as well as the usual NEEDED, INIT, FINI, etc)
Jim> You can try checking to see if an FSF binutils release works. I
Jim> don't have access to RHEL5, so I can't comment further on that.
Jim> If this doesn't help, then we will likely need a testcase that we
Jim> can use to reproduce the problem. Or you could try debugging
Jim> readelf to see what is going on.
it looks like i will need to gather some more information, but possibly
the check that the .dynamic contains a DT_HASH should also accept a
DT_GNU_HASH?
thanks for your help Jim,
d
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Use of readelf -D option
2007-04-15 4:59 ` David Arnold
@ 2007-04-15 7:48 ` H. J. Lu
2007-04-21 19:50 ` Jim Wilson
1 sibling, 0 replies; 5+ messages in thread
From: H. J. Lu @ 2007-04-15 7:48 UTC (permalink / raw)
To: David Arnold; +Cc: Jim Wilson, binutils
On Sun, Apr 15, 2007 at 09:42:47AM +1000, David Arnold wrote:
> it looks like i will need to gather some more information, but possibly
> the check that the .dynamic contains a DT_HASH should also accept a
> DT_GNU_HASH?
Please open a bug report at
http://www.sourceware.org/bugzilla/
H.J.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Use of readelf -D option
2007-04-15 4:59 ` David Arnold
2007-04-15 7:48 ` H. J. Lu
@ 2007-04-21 19:50 ` Jim Wilson
1 sibling, 0 replies; 5+ messages in thread
From: Jim Wilson @ 2007-04-21 19:50 UTC (permalink / raw)
To: David Arnold; +Cc: binutils
On Sun, 2007-04-15 at 09:42 +1000, David Arnold wrote:
> am i correct in remembering that on x86_64 and with recent binutils,
> there's only a DT_GNU_HASH?
I don't believe it is the default in the FSF tree. I see DT_HASH when I
try it on my x86_64 machine. Perhaps Red Hat applied a patch to change
the default?
There is a linker option --hash-type= that you can use to change this.
Option values are sysv, gnu, or both. So this might work as a short
term workaround.
> it looks like i will need to gather some more information, but possibly
> the check that the .dynamic contains a DT_HASH should also accept a
> DT_GNU_HASH?
It is a little more complicated than that. readelf is using the DT_HASH
info to compute the list of symbols. So we need equivalent code that
works for DT_GNU_HASH.
I'd suggest filing a bug report as HJ already mentioned. If you want
RHEL fixed, you will have to file a bug report with Red Hat.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-04-21 17:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-11 1:11 Use of readelf -D option David Arnold
2007-04-14 1:27 ` Jim Wilson
2007-04-15 4:59 ` David Arnold
2007-04-15 7:48 ` H. J. Lu
2007-04-21 19:50 ` Jim Wilson
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).