[Bug gdb/28549] ARM/Cortex-M: improper stack unwinding when the target is in lockup state

["tomas.vanek at fbl dot cz" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28549

--- Comment #50 from tomas.vanek at fbl dot cz ---
I finally submitted
https://sourceware.org/pipermail/gdb-patches/2022-October/192716.html

(In reply to Torbjörn SVENSSON from comment #49)
> 
> Right now, I'm more concerned about the endless(?) loop when the target is
> in lockup state.

Could it be explained by unwinding with wrong SP value because the size
of the next outer frame cannot be determined because of unknown pre-lockup PC?

> > 'Show frame unwinder name in signal name' gives user little bit better info
> > than <signal handler called> - it might be mergeable (I didn't check, will
> > do).
> 
> I think this patch could be an improvement, but not as important as the
> previous one. Lets focus on getting the other one in first, okay?

Because you doesn't seem to be happy with
'Show frame unwinder name in signal name'...

> I just landed a patch that shows how you can use the 
> frame_unwind_stop_reason hook to stop the unwinding. I think the same logic
> could be used in your patch too.

... and your patch made much easier to stop unwinding without misleading
messages, I simplified the change. Dedicated lockup unwinder is dropped,
I added the equal functionality to the exception unwinder.

TBH Personally I would prefer 3 dedicated unwinders: exception (EXC_RETURN),
FNC_RETURN and lockup. I think that performance penalty would be negligible
as the sniffers are simple and fast and the code would be cleaner. However I'm
not so familiar with gdb code so I respect your preference.

BTW Thanks for the pointer to
> Regarding the assurance, please see Pedro's reply to the very same question
> here: https://sourceware.org/pipermail/gdb-patches/2022-October/192655.html

and submitting your
'[PATCH v4] gdb/arm: Stop unwinding on error, but do not assert'
and
'[PATCH] gdb/arm: Don't rely on loop detection to stop unwind'

They really make a difference.
But there is a small drawback: as the warning messages are printed out in time
of building cache, they appear just once and if user e.g. repeats 'backtrace'
command he gets no more messages.


> > I wonder why arm_m_addr_is_magic() decoding differs so much in branches
> > without and with the security extension. The former decodes just the used
> > special addresses, the latter whole pages with lot of 'undefined behaviour'
> > codes.
> 
> On
> https://developer.arm.com/documentation/100701/0200/The-EXC-RETURN-register,
> it's written as that 0xffxxxxxx is an EXC_RETURN pattern, even if there are
> combinations within that that is illegal.

Hmm, this document really looks like the devices without sec ext have just
3 listed EXC_RETURNs. 'Arm®v8-M Architecture Reference Manual', D1.2.95
'EXC_RETURN, Exception Return Payload' makes clear that the payload format and
bits assignment are same for both with and without sec ext, just some bits are
reserved in the case 'without sec'.
So IMO detecting EXC_RETURN on a device with security extension should treat
reserved bits same way as doing so on dev w/o sec, not to do the quite
opposite.

And one more suspicious point: ARMv8-M RM describes the FType bit 4
as it does not depend on sec ext. Correct me if I'm wrong it would mean
that ARMv8-M device with FP and without security used also 0xFFFFFFA0,
0xFFFFFFA8 and 0xFFFFFFAC EXC_RETURNs. I don't have such device
neither I'm not aware of any, it even does not exist at all.

BTW it's quite easy to trigger the internal error at the end of
arm_m_exception_cache(). Just set PC register to any of magic codes
(I admit that doing so has little sense except showing another reason to check
the reserved bits):

On STM32L5 ARMv8-M with sec ext:

(gdb) set $pc=0xff000000
../../gdb/arm-tdep.c:3684: internal-error: While unwinding an exception frame,
found unexpected Link Register value 0c0002cb.  This should not happen and
maybe caused by corrupt data or a bug in GDB.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x8119852 gdb_internal_backtrace_1
        ../../gdb/bt-utils.c:122
0x8119852 _Z22gdb_internal_backtracev
        ../../gdb/bt-utils.c:168
0x843a40c internal_vproblem
        ../../gdb/utils.c:396
0x843a79e _Z15internal_verrorPKciS0_Pc
        ../../gdb/utils.c:476
0x8528326 _Z14internal_errorPKciS0_z
        ../../gdbsupport/errors.cc:58
0x80cf181 arm_m_exception_cache
        ../../gdb/arm-tdep.c:3689
0x80cff77 arm_m_exception_this_id
        ../../gdb/arm-tdep.c:3703
0x8257bbe compute_frame_id
        ../../gdb/frame.c:594
0x8257e49 _Z12get_frame_id14frame_info_ptr
        ../../gdb/frame.c:637
0x825b185 _Z16frame_find_by_id8frame_id
        ../../gdb/frame.c:906
0x8447bbf _Z12value_assignP5valueS0_
        ../../gdb/valops.c:1304
0x8226a46 _ZN10expression8evaluateEP4type6noside
        ../../gdb/eval.c:101
0x8226e8e _Z19evaluate_expressionP10expressionP4type
        ../../gdb/eval.c:115
0x8328a4e set_command
        ../../gdb/printcmd.c:1519
0x814b1aa _Z8cmd_funcP16cmd_list_elementPKci
        ../../gdb/cli/cli-decode.c:2543
0x84001bb _Z15execute_commandPKci
        ../../gdb/top.c:692
0x822dff4 _Z15command_handlerPKc
        ../../gdb/event-top.c:616
0x822e366 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
        ../../gdb/event-top.c:860

On Kinetis K22, Cortex-M4 FP:

(gdb) set $pc=0xFFFFFFBC
the same error follows...

-- 
You are receiving this mail because:
You are on the CC list for the bug.