Re: [RFC][PATCH] arm-tdep.c (arm_m_exception_cache): Handle stack switching to PSP during exception unwind.

[Yao Qi <yao at codesourcery dot com>]

Pedro Alves <palves@redhat.com> writes:

> Let's start by fixing this properly, please.  If GDB needs to know
> about these registers, then they should be part of a known feature
> in the target description.  According to B1.4 in the same document,
> we see:
>
> "The ARMv7-M profile has the following registers closely coupled to the core:
>
> - general purpose registers R0-R12
> - 2 Stack Pointer registers, SP_main and SP_process (banked versions of R13)
> - the Link Register, LR (R14)
> - the Program Counter, PC
> - status registers for flags, exception/interrupt level, and execution state bits
> - mask registers associated with managing the prioritization scheme
> for exceptions and interrupts
> - a control register (CONTROL) to identify the current stack and
> thread mode privilege level.
> "
>
> Seems like even more core things other than SP_main/SP_process are
> missing from org.gnu.gdb.arm.m-profile, when debugging at this level.
>

If we add more registers to feature org.gnu.gdb.arm.m-profile, xml files
provided by gdb stubs (such as openocd) have to be updated too,
otherwise GDB will reject the target description, right?  Does this
cause any compatibility issue? new gdb rejects the target description
from old openocd.

>> 
>>> +    gdb_assert (pspreg != -1);
>> 
>> This is too strong to me.  If the process sp isn't found, it means GDB
>> stub doesn't provide process sp in the target description or the name of
>> process sp isn't recognized by GDB.  It is not GDB's fault.  We can emit
>> an error here, IMO.
>> 
>>> +
>>> +    regcache = get_current_regcache ();
>>> +    pspval = regcache_cooked_read_value (regcache, pspreg);
>> 
>> In general, getting the register value in unwinding from current
>> regcache is wrong, because register value should be got from the
>> previous frame.  However, in the case that getting process sp in
>> exception on cortex-m, it is correct.  At this point, the program is
>> still in exception, and main sp is used (process sp isn't used nor changed).
>> When GDB is unwinding frames from the exception to the application, the
>> process sp register is still valid.
>
> I suppose this would still break if we have nested exceptions.
>

For nested exceptions, it returns to handler mode, so the return address
(EXC_RETURN) is 0xfffffff1.  In this case, EXC_RETURN is 0xfffffffd, it
returns to thread mode, so can't be in nested exceptions.

> Would it not work to get the register from the frame instead of
> the regcache directly?  If nothing saves/clobbers it up the frame
> chain, the sentinel frame will end up unwinding/reading it from
> the current regcache just the same.

Agreed.  It is better to get register from frame.  However, we need to
extend standard feature org.gnu.gdb.arm.m-profile first, as you said.

-- 
Yao (éå)