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

[Roul Oldenburger <oldenburger dot roul at rheinmetall-de dot com>]

Hi Nick,

you are right I am going to start on the "circular debug info" message 
and try to find out why it is generated, but there is a new situation 
and this probably leads to a different solution. I like to ask you this 
first before I look at objdump's code.

The situation was objdump on one machine generated useful 
debuginformation output but the same version of objdump on a different 
machine didn't.
From the libs situation we tried and built a static version of objdump.
This objdump gave useful output on both machines using the same executable.

Now what happened -
I wrote a small test program intended to reproduce a complex debug info 
data. The code is part of a bigger program and almost copied. I simply 
wanted to have less debug info output which is clearly to read.

I compiled and linked it (trying to do it) the same way the bigger 
program is compiled and linked on the same machine.

Now running the static version of objdump on the test executable I get 
the "circular debug info" message and '<undefined>' type definitions 
again. Using the same static version of objdump on the bigger executable 
I do not get these problems.

What do you think about this ?
I would think this is not or at least not alone an objdump issue.

On a different question I am in contact with the gdb mailing list (Joel 
Brobecker) - investigating the Ada specific symbols GNAT adds to the 
debug information when compiling the executable.
Could this be a bug in GNAT or gcc that under some circumstances has 
problems to generate correct debug information for certain data types or 
combinations of types? When trying to debug the test executable using 
ddd I get 'No symbol xyz in current context' if I try to print or 
investigate the variable or type components ... but on the other hand 
the values I do expect are shown in the info display for 'locals' ... I 
do not understand this.

If you want to have a try on it here is the code I am using

-----------------------------------------------
with Text_Io;

procedure XVL_Array_test is
subtype Index is Integer;

type Freq_Lengths_Type is
    array ( Index range <> )
  of Index;

Bdt_Cas_Freq_Lengths : constant Freq_Lengths_Type( Index range 1..2 ) := 
( 46, 0 );
Bdt_Fas_Freq_Lengths : constant Freq_Lengths_Type( Index range 1..2 ) := 
( 18, 0 );
Bdt_Tas_Freq_Lengths : constant Freq_Lengths_Type( Index range 1..2 ) := 
( 19, 0 );

Bdt_Cas_Bands : constant Index := Bdt_Cas_Freq_Lengths(1);
Bdt_Fas_Bands : constant Index := Bdt_Fas_Freq_Lengths(1);
Bdt_Tas_Bands : constant Index := Bdt_Tas_Freq_Lengths(1);

type Spectral_Table is
  array (Index range <>) of Float;

type Bdt_Spectral_Description is
  record
    Cas : Spectral_Table(1 .. Bdt_Cas_Bands):= (others => 0.0);
    Fas : Spectral_Table(1 .. Bdt_Fas_Bands):= (others => 0.0);
    Tas : Spectral_Table(1 .. Bdt_Tas_Bands):= (others => 0.0);
  end record;

MAX_NOISE_FILTER : constant Index := 16;

type Bdt_Spectral_Table
is array ( Index range 1 .. MAX_NOISE_FILTER ) of aliased 
Bdt_Spectral_Description;

My_Bdt_Spectral_Table_Array : Bdt_Spectral_Table;

begin

  Text_Io.Put_Line("Size of the entire array: " & 
Integer'Image(My_Bdt_Spectral_Table_Array(1)'Size /8 * 
My_Bdt_Spectral_Table_Array'Length));

end XVL_Array_Test;
---------------------------------------------

I am looking forward for your answer.
Thankyou

Roul


Nick Clifton wrote:
> Hi Roul,
>
>
> > 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
>
>
> > As I understood 1. libbfd isn't dynamically linked
>
>
> Yup.
>
>
> > 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.
>
>
> Also correct.  It looks like the other machine has an older version of
> glibc installed on it.  (Or at least installed on it in such a way
> that it is found before other versions of glibc).
>
>
>
> > 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.
>
>
> Well, that is not guaranteed, but it does look like the problem is not
> due to a memory corruption bug.
>
>
>
> > But before I start debugging objdump I like to know your opinion.
>
>
> It sounds like your best bet now is going to be to start at the
> "circular debug info" message and work backwards from there.  ie find
> out *why* this message is being produced and whether it is being
> correctly produced or if it is the result of an uninitialised variable
> or some other kind of bug.
>
> Cheers
>         Nick
>         

--
Mit freundlichen Grüßen

^-----------------------------------------------------------+
| Rheinmetall Defence Electronics GmbH     Brüggeweg 54     |
|                                          Postbox 44 84 44 |
| Roul Oldenburger                         28284 Bremen     |
| SPMU                                     Germany          |
| Software Development                                      |
|                                                           |
|      Phone: +49 421 457 2410                              |
|      Email: oldenburger.roul@rheinmetall-de.com           |
|      Web:   http://www.rheinmetall.com/                   |
|             http://www.rheinmetall-de.com/                |
*-----------------------------------------------------------/