This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: objdump: circular debug information error message // <undefined>types in output
- From: Roul Oldenburger <oldenburger dot roul at rheinmetall-de dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 12 Nov 2003 12:36:48 +0100
- Subject: Re: objdump: circular debug information error message // <undefined>types in output
- Organization: Rheinmetall Defence Electronic
- References: <3FB0D4E6.5060002@rheinmetall-de.com> <m3ekwf557d.fsf@redhat.com>
Hi Nick,
thankyou very much for your help!
First I took the daily snapshot of binutils from yesterday (031111) and
compiled it on both machines. Unfortunately that made no difference to
the other versions I tried before.
Because I was thinking of shared libs used by objdump which might cause
the trouble I had a look with ldd which gave me the next riddle ...
objdump 2.14 on my machine:
libc.so.6 => /lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Version information:
../Desktop/betr_binutils/binutils-2.14/binutils/objdump:
libc.so.6 (GLIBC_2.2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2
objdump 2.14 on the other machine:
libc.so.6 => /lib/libc.so.6 (0x4001e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Version information:
binutils-2.14/binutils/objdump:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2
As I understood 1. libbfd isn't dynamically linked and 2. the only
difference in here is
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
which I think means that objdump on the other machine uses a different
version of glibc.
Then we built a static version of objdump on my machine using the 031111
snapshot.
It seems like this executable works the same way on the other machine as
it does on my machine .... no 'circular debug info' messages and no
'<undefined>' type designators !! :-)))
However I like to know why it is like that and set MALLOC_CHECK_ which
answered on each test with the different objdumps
malloc: using debugging hooks
but nothing else ... so I guess there is nothing wrong happening with
malloc.
But before I start debugging objdump I like to know your opinion.
Thanks
Roul
Nick Clifton wrote:
Hi Roul,
What I also found is that using the same version of binutils on the
same executable but on a different machine ... there are no warnings
about circular debug info given and the <undefined> entries are
changed into the type I do expect.
Question: What did I wrong? What can I do to find out?
If the same version of binutils works on one machine but not another -
and the two machines had different operating systems - then it is
almost certainly a bug in binutils. (It is probably related to the
memory returned by malloc(). Under some OS's the memory is zero'ed
before hand on others it is not). If the two machines were basically
identical - ie running the same OS and with the same versions of all
the software packages installed - then it is most likely to be a
hardware bug on the failing machine - perhaps a damaged memory module.
Things to try:
* Download the latest binutils sources from the CVS repository or
one of the daily snapshots, build yourself a new version of
objdump and see if the problem still exists.
* If your OS provides a debugging memory allocator then try using
that. For example under Linux you can often define an environment
variable called MALLOC_CHECK_ to enable a special, paranoid
version of malloc to be used.
* Create a *small* binary that shows the problem and post it to the
list along with precise instructions on how to make the bug
appear.
* Debug the problem yourself. You have access to the sources, you
can add printf statements, run the program under a debugger, etc.
Am I right if I guess the local objdump still uses the libbfd from
the installed 2.11 ?
It depends upon whether you built a version of objdump that uses
shared libraries. If it does then it will use the system installed
version of libbfd (ie 2.11). If you have built a static version of
objdump then it will use the version of libbfd built into it (ie
2.14).
Cheers
Nick