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

[Pedro Alves <palves@redhat.com>]

On 03/15/2012 06:26 AM, Jonathan Larmour wrote:

> On 14/03/12 16:06, Pedro Alves wrote:
>> On 03/11/2012 03:36 AM, Jonathan Larmour wrote:
>>>
>>> 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).
> 
> Ah ok, that's what I was missing. And that uses gdbarch_num_regs() which
> corresponds to arm-tdep.h's ARM_NUM_REGS which includes all possible
> registers, both VFP and FPA. And later the 'g' packet is shrunk.
> 
> So, just to be clear, if neither the user nor target supplies a tdesc, the
> block in arm_gdbarch_init() starting with:
>    if (tdesc_has_registers (tdesc))
> will never be run? If that's the case, no need to answer. Or is
> arm_gdbarch_init() called a second time after the remote 'g' packet
> guessing occurs (which has selected a tdesc)?


It is called a second time.  You can try putting a breakpoint
there and see what happens.

From reading the code, we'll reach:

      /* 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 ();
	}

and target_find_description will call gdbarch_update_p, which should
end up in gdbarch_find_by_info calling:

  /* Ask the tdep code for an architecture that matches "info".  */
  new_gdbarch = rego->init (info, rego->arches);

Which will end up in arm_gdbarch_init creating a new gdbarch
modelled on the guessed target description (after the checks), since no
gdbarch has this tdesc yet.

-- 
Pedro Alves