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/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