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