Output format documentation

Output format documentation

[Andrew STUBBS]

Hi all,

I am trying to find out what the more mysterious columns mean in the 
output from the various binutils utilities.

E.g. What do the 'l', 'd', 'f' and zeros mean in the following?

# objdump -t sh-stub.exe

sh-stub.exe:     file format elf32-little

SYMBOL TABLE:
a0000000 l    d  .text  00000000
a8000000 l    d  .data  00000000
a8000000 l    d  .bss   00000000
a8000a00 l    d  .stack 00000000
00000000 l    d  .comment       00000000
00000000 l    d  .debug_abbrev  00000000
00000000 l    d  .debug_info    00000000
00000000 l    d  .debug_line    00000000
a0002930 l    d  .rodata.str1.4 00000000
00000000 l    d  .debug_frame   00000000
00000000 l    d  .debug_pubnames        00000000
00000000 l    d  .debug_aranges 00000000
00000000 l    d  .debug_str     00000000
00000000 l    d  .note.GNU-stack        00000000
00000000 l    d  *ABS*  00000000
00000000 l    d  *ABS*  00000000
00000000 l    d  *ABS*  00000000
00000000 l    df *ABS*  00000000 entry.S
00000000 l    df *ABS*  00000000 linkage.h
00000000 l    df *ABS*  00000000 entry.S
00000000 l    df *ABS*  00000000 config.h
00000000 l    df *ABS*  00000000 entry.S
00000000 l    df *ABS*  00000000 <command line>
00000000 l    df *ABS*  00000000 <built-in>

00000000 l    df *ABS*  00000000 entry.S
ffffffd0 l       *ABS*  00000000 TRA
ffffffd4 l       *ABS*  00000000 EXPEVT
ffffffd8 l       *ABS*  00000000 INTEVT
fffffe9c l       *ABS*  00000000 TMU0_TCR
a0000044 l       .text  00000000 CCR_A
a0000048 l       .text  00000000 CCR_DISABLE
a000004c l       .text  00000000 CCR_D
etc...

This is just one example of the sort of indecipherable output one gets 
from these tools.

I have looked in the official documentation and searched the web a 
little, but can't find any clues there. nm is not completely without a 
description, but that appears to be the exception to the rule, and even 
then it is fairly minimal.

I can of course look in the source code, but that is not exactly 
convenient and guessing things from variable names etc. isn't exactly 
what I had in mind. For example, the 'd' above would appear to have 
something to do with debugging (according to bfd_print_symbol_vandf), 
but in what way remains vaguely mysterious.

Is there some documentation I have missed?

Whether or not there are any now, please can I request that somebody in 
the know inserts some useful descriptions into the official docs for the 
next version of binutils. Some column header in the tool output might 
not be a bad plan either. I know there is a problem in that the 
different data formats have different output, but at least the most 
common one ought to have something written.

Thanks very much

Andrew Stubbs

Re: Output format documentation

[Ian Lance Taylor]

Andrew STUBBS <andrew.stubbs@st.com> writes:

> E.g. What do the 'l', 'd', 'f' and zeros mean in the following?

> SYMBOL TABLE:
> a0000000 l    d  .text  00000000

'l' means a local symbol.

'd' means a debugging symbol.

'f' means a file symbol.

> Is there some documentation I have missed?

Probably not.

> Whether or not there are any now, please can I request that somebody
> in the know inserts some useful descriptions into the official docs
> for the next version of binutils. Some column header in the tool
> output might not be a bad plan either. I know there is a problem in
> that the different data formats have different output, but at least
> the most common one ought to have something written.

The documentation does indeed have many weaknesses.  Patches are
welcome.

Ian

Re: Output format documentation

[Andrew STUBBS]

Ian Lance Taylor wrote:
> Andrew STUBBS <andrew.stubbs@st.com> writes:
>>SYMBOL TABLE:
>>a0000000 l    d  .text  00000000
> 
> 'l' means a local symbol.
> 
> 'd' means a debugging symbol.
> 
> 'f' means a file symbol.
> 
>>Is there some documentation I have missed?
> 
> Probably not.

Then how do you know? Ok, silly question, but you get my point. I notice 
that you make no attempt the explain the '00000000'.

>>Whether or not there are any now, please can I request that somebody
>>in the know inserts some useful descriptions into the official docs
>>for the next version of binutils. Some column header in the tool
>>output might not be a bad plan either. I know there is a problem in
>>that the different data formats have different output, but at least
>>the most common one ought to have something written.
> 
> 
> The documentation does indeed have many weaknesses.  Patches are
> welcome.

I don't really have time for our own documentation, never mind anybody 
else's, and yes, I'm sure the same is true for many people which is why 
the docs are so short in the first place.

That said, I might be able to find a little time now and again to have a 
bash, but it still wouldn't do any good because I wouldn't be able to 
come up with anything better than that you put above. I mean, 'd' might 
be a debugging symbol, and I already guessed that from the source, but 
what does it mean for a symbol to have this flag? What does it mean to 
have a nameless symbol like the one above? Why are filenames listed as 
symbols? How come that column can be either 'd' for debug or 'D' for 
dynamic? That's the sort of information that should be in the docs, and 
that's the stuff only insiders can really know.

Sigh, if somebody were to explain it to me I might find time to have a 
go at a patch, slowly, in between other work.

Andrew

Re: Output format documentation

[Ian Lance Taylor]

Andrew STUBBS <andrew.stubbs@st.com> writes:

> Ian Lance Taylor wrote:
> > Andrew STUBBS <andrew.stubbs@st.com> writes:
> >>SYMBOL TABLE:
> >>a0000000 l    d  .text  00000000
> > 'l' means a local symbol.
> > 'd' means a debugging symbol.
> > 'f' means a file symbol.
> >
> >>Is there some documentation I have missed?
> > Probably not.
> 
> Then how do you know? Ok, silly question, but you get my point. I
> notice that you make no attempt the explain the '00000000'.

It's the size of the symbol, as set by the .size pseudo-op in the
assembler source.  0 is the default value if the size is not set.

> That said, I might be able to find a little time now and again to have
> a bash, but it still wouldn't do any good because I wouldn't be able
> to come up with anything better than that you put above. I mean, 'd'
> might be a debugging symbol, and I already guessed that from the
> source, but what does it mean for a symbol to have this flag?

It means that symbol exists primarily for debugging purposes.  The
main effect of that flag is that the symbol will be removed if you do
strip -g.

> What
> does it mean to have a nameless symbol like the one above?

Nothing much.  It just means that the symbol has no name.  This is
typical for STT_SECTION symbols.

> Why are
> filenames listed as symbols?

Because the compiler emitted a .file pseudo-op, which caused the
assembler to create a STT_FILE symbol.

> How come that column can be either 'd'
> for debug or 'D' for dynamic? That's the sort of information that
> should be in the docs, and that's the stuff only insiders can really
> know.

There is actually no reason for this.  When I added BSF_DYNAMIC I
didn't want to add any more columns.  I figured that there would never
be a dynamic debugging symbol--in general, dynamic symbols are only
the ones which the dynamic linker needs--so I reused the same column.

I fully agree that objdump output should be better documented.  But I
want to note that the output is not designed for general purpose
use--that is what nm is for.  The output of objdump -t varies
depending on the file format, and is mainly for people who are already
aware of object file details.

Ian