Use of readelf -D option

Use of readelf -D option

[David Arnold]

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

Re: Use of readelf -D option

[Jim Wilson]

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

Re: Use of readelf -D option

[David Arnold]

-->"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

Re: Use of readelf -D option

[H. J. Lu]

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.

Re: Use of readelf -D option

[Jim Wilson]

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