This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: meaning of this objdump output?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Phil Edwards <pedwards at disaster dot jaj dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 26 Nov 2001 18:39:56 -0500
- Subject: Re: meaning of this objdump output?
- References: <20011126183957.A8064@disaster.jaj.com>
On Mon, Nov 26, 2001 at 06:39:57PM -0500, Phil Edwards wrote:
> The output of objdump -t is documented to be "similar to the information
> provided by the `nm' program." Except that it isn't. Reading through
> the code, '-t' forwards to bfd_print_symbol(), which is a macro wrapper
> around something horrible. :-) That's where I gave up.
>
> For example,
>
> 47% nm -C libstdc++.so | grep S_free_list
> 0009d640 B std::__default_alloc_template<true, 0>::_S_free_list
> 48%
>
> nm's documentation explains to me (and more importantly, my coworkers!) what
> the B means. No problems there, nm is a common tool.
>
> But this output
>
> 49% objdump -t -C -j .bss libstdc++.so | grep _S_free_list
> 0009d640 g O .bss 00000080 std::__de[ trim long name ]
> 50%
>
> isn't similar, doesn't correspond, and isn't documented. My coworkers
> could figure out the address field (obvious), and the ".bss" and "00000080"
> fields were obvious to me, but none of us can tell what the "g" and "O" are.
The 'g' is Global, and the 'O' is Object. This really needs to be
better documented :)
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer