symbol table question

["Andrew Begel" <abegel at eecs dot berkeley dot edu>]

I'm using Mingw's GCC 2.95.2-3 (3/29/01), and I'm compiling some C++
classes and functions to be dllexport'd through a DLL. When I compile my
.cc file into a .o, and then use objdump --all-headers blah.o, I get
this output:

[Tue 8:37pm ] abegel@JUNIPER> objdump --all-headers bar.o | grep
nth_parent
[ 17](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x00000058
_nth_parent__C3MooPC3Moo

This line is from the symbol table. Notice that for my dllexport'd
function Moo::nth_parent(Moo *) the nx (num-auxiliary entries) field of
the symbol table is 1. 

When I then turn this guy into a DLL (using c++ -shared), I get this
extra line in my objdump:

[Wed 4:59pm ] abegel@JUNIPER> objdump --all-headers bar.dll | grep
nth_parent
        [   1] nth_parent__C3MooPC3Moo
[ 17](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x00000058
_nth_parent__C3MooPC3Moo 

This first line is from the --private-headers, and I assume it's saying
that nth_parent is dllexported from the DLL and ready to be imported by
someone else.

And in fact, when I dllimport the symbol into another binary I've got,
everything works well. 

-------

Now, in another file that I'm compiling, I do the same dllexporting, but
when I do an objdump --all-headers, my nx field is 0:

[461](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00002a80
_nth_parent__C4Nodei

And, if I go through the trouble of linking a dll, I don't get the extra
line from the private headers. And when I try to use the exported symbol
by dllimporting it, I eventually get a link error that the symbol isn't
defined by the dll. 

---
The question: What can I do to debug my .o and symbol tables? Is the nx
field a valid way to tell from the .o that the symbol being looked at is
going to be dllexport'd? If so, what is the other piece of into that the
nx 1 field is mentioning? If not, how can I tell from the .o file
whether or not a given symbol was correctly compiled as dllexport'd?

Thanks,

Andy Begel