Re: RFC: printing pointers to global (data) variable on Windows...

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel>     if (msymbol != NULL
Joel>         && MSYMBOL_SIZE (msymbol) == 0
Joel>         && MSYMBOL_TYPE (msymbol) != mst_text
Joel>         && MSYMBOL_TYPE (msymbol) != mst_text_gnu_ifunc
Joel>         && MSYMBOL_TYPE (msymbol) != mst_file_text)
Joel>       msymbol = NULL;

I think the reason for this is here:

    http://sourceware.org/ml/gdb-patches/2012-04/msg00175.html

text symbols are allowed since without them (according to a later
message) asm-source.exp would regress.

Joel> I looked at the COFF/PE documentation, and I do not think that there
Joel> is a way to provide the size of each symbol in the symbol table.
Joel> So the block of code above discards our minimal symbol entry due to
Joel> the size (always) being zero. And since our global is not a function,
Joel> we do not find anything from the debugging info either.

Joel> Does anyone know why we have the block discarding zero-sized non-text
Joel> symbols? I ran the testsuite on x86_64-linux, and got no regression.

I wonder what happens if you set the symbol sizes to 1.

Ok, horrible idea.  Perhaps some flag bit on the minsym instead?
Or on the objfile?

Joel> My second question is regarding the fact that we looking symbols for
Joel> functions only. This probably made sense if the function was used for
Joel> text addresses (like disass), but does it now?  Or perhaps it's the
Joel> GNU/Linux output that should be fixed, and only text symbols should
Joel> be printed when printing addresses (somehow, I do not think that this
Joel> would be right).

IIRC the full symbol tables only record address information for text
symbols, not for data symbols.  If so, one cannot do this lookup.

That's what I remember from when I wrote this change.  It would be nice
to be wrong since the current approach means we can't always print a
sensible answer for users.

Tom