This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: objdump: interpretation of stabs debuginformation


Roul Oldenburger <oldenburger.roul@rheinmetall-de.com> writes:

> But using the recent version, objdump's output looks almost like I need it.
> Are the ids assigned the same way the type numbers are?

Well, in a sense I suppose they are.  The IDs are just assigned
sequentially.  They let you disambiguate different structures (or
whatever) with the same name.

> Is there a document explaining how the output is to interpret?
> What I mean is - which might be the right way to parse the information
> automatically?

Well, no.  My intention was to provide a human readable version of the
debugging information, not a machine readable version.  My thinking
was that there already was a machine readable version, namely the
debugging information itself.  objdump --debugging gives people a
convenient way to look at the debugging information without having to
interpret the debugging data itself.

Actually, objdump --debugging was a fallout of work I did to permit
automatically converting debugging information from one format to
another.

> struct awu_siso_shared_memory__exercise_description { /* size 16 id 3229 */
>    awu_siso_shared_memory__exercise_status_selection___XDLU_0__4
> status; /* bitsize 8, bitpos 0 */
>    integer noofselectedstations; /* bitsize 32, bitpos 32 */
>    struct awu_siso_shared_memory__speed_range_description /* id 3294
> */ speed; /* bitsize 64, bitpos 32 */
>    awu_siso_shared_memory__stationsselectedarray selectedstations; /*
> bitsize 48, bitpos 64 */
> };
> 
> In some cases it is obvious .. a component is a substructure, another
> is an integer or other basic type but in other cases it is an enum or
> an array of another structure, which is not shown at once.

When there is a reference to another enum or another struct which is
not defined, that is generally a reflection of the actual debugging
information itself.  Debuggers normally have to build a table across
the entire program in order to get accurate definitions of all types.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]