Re: [PATCH,tests] Run to main before doing any tests in structs3.exp

[Luis Machado <lgustavo@codesourcery.com>]

Joe,

On 11/06/2012 10:26 PM, Joel Brobecker wrote:
>> Consider, for example, a target that runs on QEMU. QEMU won't start
>> the binary in exactly the same way as gdbserver running on linux.
>> Thus, global variable initialization procedures may not have
>> happened at that point yet. Consider that we start even before the
>> dynamic loader had a chance to run and do all the relocation magic.
>
> The part I don't get is why this even enters the picture. If it was
> a C++ program, with elaboration code that's run when the binary is
> loaded in memory, I would understand. But this is a plain C program,
> where I imagine the variables are simply located in data, with their
> default value provided there. So, even if the program hasn't started
> at all, GDB should be able to fetch it from the binary.
>
> That being said, I don't want to hold your patch. I think it's fine
> to run the program till main. I was just curious as to why this was
> sometimes necessary. Still can't get it :-).
>

I find the discussion and in-depth view really important, so i 
appreciate your comments.

There is, of course, an explanation. :-)

The real issue arises from two points:

1 - As Pedro mentioned, the testsuite does not start the inferior for 
native debugging, but does so for remote targets.

2 - On startup, some targets relocate the binary's sections during 
inferior execution. When this happens, data is shifted from location X 
to location Y.

In the specific case of structs3, we have "two", the structure, and 
"twop", a pointer to the structure.

The whole structure is properly relocated, so attempting to print "two" 
will yield the correct result.

When gdb tries to print the contents of "twop", that's where the problem 
shows up.

Though "two" and "twop" have been properly relocated, the value of 
"twop" is still pointing at the location before relocation, thus the 
printed values are wrong.

The contents of "twop" will eventually be fixed up by a dynamic 
relocation during ld.so's execution (which, in my case, did not start yet).

Pedro's suggestion of simply loading the binary via gdb_file_cmd works 
for me though. So there is no need to effectively start the inferior.

Luis