This is the mail archive of the binutils@sourceware.org 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: Output format documentation


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


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