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

Tom Tromey
2012-08-16T20:07:03Z

>>>>> "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