objdump: circular debug information error message // <undefined> types in output

[Roul Oldenburger]

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