Re: Fwd: Re: [patch] Add support for ARMv7M devices.

[Pedro Alves <palves@redhat.com>]

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 (&current_target);

  /* If that failed try a target-specific hook.  */
  if (current_target_desc == NULL)
    current_target_desc = target_read_description (&current_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