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

Joel Brobecker
2012-08-16T15:23:14Z

Hello,

I have a piece of code that defines a struct with one of the fields
being a "char *". The field gets set to a global variable:

char my_name[] = "MyName";

k = {my_name, [...]};

When trying to print key.system_name on Windows, we get:

(gdb) p k.system_name
$2 = 0x403000 "MyName"

We're missing the reference to the global "my_name". On GNU/Linux,
we get:

(gdb) p k.system_name
$3 = 0x6008e8 <my_name> "MyName"

I couldn't understand why this wasn't working, since GDB does not seem
to have any problems determining what symbol is at 0x403000:

(gdb) info symbol 0x403000
my_name in section .data of c:\[...]\lb.exe

Debugging GDB, I found the following block of code in build_address_symbolic:

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

Basically, build_address_symbolic searches for symbol names two
ways: through the minimal symbols, and through the symbol table,
but only function symbols:

msymbol = lookup_minimal_symbol_by_pc_section (addr, section);
symbol = find_pc_sect_function (addr, section);

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

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

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

At the moment, I am thinking that the proper fix would probably be
two ways: ditch the block discarding zero-sized non-text symbols
(this breaks with symbol tables whose format do not allow for symbol
sizes), and also search all global symbols, rather than just functions.

Thoughts?

Thank you,
--
Joel

PS: I do not think that the problem is specific to the fact that this
is a field inside a struct. I am pretty sure that the same would
happen with a simple "char *" variable. But that's what I used for
my investigation.