This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi Joel,

On 11/06/2012 03:30 PM, Joel Brobecker wrote:
On remote targets, we don't always start at the entry point. Thus,
it is safer to get to main and do the tests from that point onwards.

Can you elaborate more? Your patch looks reasonable at first sight, but then at the same time now introduces a new requirement that it needs to be run on the target, whereas that was not the case before.

The testcase only prints global variables. I don't suppose there
is much of a guaranty that you could print global variables without
starting the program first, but it's been generally working. So
I am curious as to why it isn't working in your case.

We've been generally only testing these with native targets or with gdbserver on linux, both of which have well-known inferior startup procedures.


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.

In this case, it makes no sense to try to print global variables since they will only contain garbage.

Effectively starting the binary and running to a known location helps avoid such a situation, and it does not change much for targets that already passed these tests.

Hopefully this explains things a little better.

Luis


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]