This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Fwd: Re: [patch] Add support for ARMv7M devices.
On 03/11/2012 03:36 AM, Jonathan Larmour wrote:
> On 09/03/12 16:28, Pedro Alves wrote:
>> On 03/09/2012 04:13 PM, Jonathan Larmour wrote:
>>>
>>> But you have made me think of one improvement: we should probably not call
>>> register_remote_g_packet_guess() if tdesc_has_registers (tdesc) - because
>>> if someone has directly supplied a target description, we should solely
>>> use that, and avoid any guessing.
>>
>>
>> I think that's always true, irrespective of a g packet guess being
>> installed. See target_find_description: it's always "file > target xml > g-guesses",
>
> Can you just clarify to me how, for example, a program using VFP registers
> (such as for Cortex-M4) would use the correct 'g' packet size? The
> registers correspond to the tdesc, and not to either of the guessed sizes.
> I guess if I could understand that example, I'll be happy. You can do this
> off list if you like, to save others from boredom.
Even without a description, and before connecting to the remote side,
GDB already has a clue of the target's architecture, inferred from the
executable. GDB updates target_gdbarch based on that, and sets an initial
expected size of the g packet based on the register set it things the
target has (based on what it figured out from the executable).
static void *
init_remote_state (struct gdbarch *gdbarch)
{
...
/* Record the maximum possible size of the g packet - it may turn out
to be smaller. */
rsa->sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa->regs);
If it turns out to be smaller, GDB will re-adjust (process_g_packet).
Or did you mean, in the case where the target does send over a
target description? The g packet size guesses are only used when the target
does _not_ send in a target description. So, GDB, during the initial
remote connection, calls target_find_description:
void
target_find_description (void)
{
/* If we've already fetched a description from the target, don't do
it again. This allows a target to fetch the description early,
during its to_open or to_create_inferior, if it needs extra
information about the target to initialize. */
if (target_desc_fetched)
return;
/* The current architecture should not have any target description
specified. It should have been cleared, e.g. when we
disconnected from the previous target. */
gdb_assert (gdbarch_target_desc (target_gdbarch) == NULL);
/* First try to fetch an XML description from the user-specified
file. */
current_target_desc = NULL;
if (target_description_filename != NULL
&& *target_description_filename != '\0')
current_target_desc
= file_read_description_xml (target_description_filename);
/* Next try to read the description from the current target using
target objects. */
if (current_target_desc == NULL)
current_target_desc = target_read_description_xml (¤t_target);
/* If that failed try a target-specific hook. */
if (current_target_desc == NULL)
current_target_desc = target_read_description (¤t_target);
Which you can see first checks for a description as set by "set tdesc filename",
and if that doesn't work, tries to fetch a description off the target, and only
if that doesn't work, it'll call target_read_description, which maps to
remote_read_description, which returns a guess based on the size of the g
packet, as registered on the gdbarch. So if the target replied back a
xml target description, we'll never read the target_read_description call.
There's actually a wrinkle: during the first call to target_find_description,
we haven't yet fetched the remote thread and inferior's status, and haven't yet
added them to our tables. So that first very initial time,
remote_read_description returns nothing. Right after fetching the remote
target's status, we then try again:
/* If we could not find a description using qXfer, and we know
how to do it some other way, try again. This is not
supported for non-stop; it could be, but it is tricky if
there are no stopped threads when we connect. */
if (remote_read_description_p (target)
&& gdbarch_target_desc (target_gdbarch) == NULL)
{
target_clear_description ();
target_find_description ();
}
But again, if the target or the user have already specified a description,
the if predicate is false. If we don't have a description yet, we'll end up
in target_find_description -> remote_read_description, which will no return the
best description for the gdbarch based on the g packet size.
Of course, the g-guesses are registered on specific gdbarch's. So GDB already
needs to have a clue of the target's gdbarch for g-packet guesses to work.
And again, it gets that initial target_gdbarch from the executable.
--
Pedro Alves