jasonmolenda wrote:
Thanks for digging in to this. As you noticed, I sidestepped the lldb part of
the issue in AArch64 debugserver, by having debugserver decode the instruction
at $pc, and if it is a BRK with a specific immediate value, advancing $pc past
the instruction so the user can continue execution, for a builtin_debugtrap.
I'm trying to do a little mental exercise of an arm/thumb program. StopInfo's
PerformAction will call
```
auto platform_opcode =
platform_sp->SoftwareTrapOpcodeBytes(target.GetArchitecture());
```
the ArchSpec here will be armv7 or aarch32. The `size` field will default to
0. Then in Platform we check if `size==2`, and compare to the 2-byte thumb
breakpoint sequence. Else we will compare the 4-byte arm breakpoint sequence.
So if I'm debugging an arm+thumb program, and the function is in thumb mode
with a 2-byte breakpoint, we'll match a 4-byte sequence and fail.
We have an Address::GetAddressClass() that can return
`AddressClass::eCodeAlternateISA` when an Address is contained in a function
that is thumb mode.
I don't think there's any part of lldb where I see us checking the $cpsr/xpsr
register bits to see what the current processor mode is.
Note that there are some Armv7 processors which are thumb-only, the Cortex-M
processors. There is an ArchSpec::IsAlwaysThumbInstructions() method to check
if that's the type of processor; if so, it's a 2-byte breakpoint.
https://github.com/llvm/llvm-project/pull/174348
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
