objdump --debugging: problems with interpretation of dump

[Roul Oldenburger]

Hi Ian,

thanks for your answer!

We are compiling Ada sources and use the following combination of tools:

Linux:
gcc-2.95.3-124
gnat-3.13p-27
binutils-2.11.90.0.29-14

$ as --version
GNU assembler 2.11.90.0.29

gnatgcc --version
2.8.1

The debugging information are mainly stabs. The compile options are -g 
-ggdb -gstabs+

And file says
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically 
linked (uses shared libs), not stripped

Roul




Ian Lance Taylor wrote:

> 
> The debugging information in an executable is roughly the
> concatenation of the debugging information for all the objects which
> comprise the executable.  For some types of debugging information some
> duplicate information is eliminated; this duplication is typically
> caused when different objects include the same header file in separate
> compilations.
> 
> An empty struct definition like the above might mean that the struct
> was referenced in the source, but was not defined (e.g., in C, a
> simple ``struct foo;'' statement, which permits the declaration of
> pointers to the struct without actually defining the struct).  Or it
> might mean that the struct definition was eliminated in one or more
> object files, in which case you will probably find the struct
> definition elsewhere in the debugging output.
> 
> 

> 
> The id number can be used to handle different structs which happen to
> have the same name (presumably the same struct name was used in
> different object files).  All references to the same struct will have
> the same ID.
> 
> 
>>-the ___XVE name extension is
> 
> 
> That comes straight from the debugging information.  I don't know what
> it means either.
> 
> 
>>-the extensions (___XVL, ___XVA4) in the components names are or why
>>they are presented as pointer type
> 
> 
> Likewise.  Your compiler is adding that information for some reason,
> but I don't know why.
> 
> 
>>Also all bitpos are 0 ...
> 
> 
> Yes, that's rather odd, and also the bitsizes look improbably large.
> This looks like a bug.  What type of object file, and what type of
> debugging information, are you looking at?  Which compiler and
> assembler did you use to generate the objects?
> 
> Ian