Hi Kjell,
if you say these instructions are similar to function calls, then it
sounds to me like the best option would be to get lldb to treat them
like function calls. I think (Jim can correct me if I'm wrong) this
consists of two things:
- make sure lldb recognizes that these instructions can alter control
flow (Disassembler::GetIndexOfNextBranchInstruction). You may have done
this already.
- make sure lldb can unwind out of these "functions" when it winds up
inside them. This will ensure the user does not stop in these functions
when he does a "step over". This means providing it the correct unwind
info so it knows where the functions will return. (As the functions know
how to return to the original instructions, this information has to be
somewhere, and is hopefully accessible to the debugger.) Probably the
cleanest way to do that would be to create a new Module object, which
would contain the implementations of all these functions, and all of
their debug info. Then you could provide the unwind info through the
usual channels (e.g. .debug_frame), and it has the advantage that you
can also include any other information about these functions (names,
line numbers, whatever...)
pl
On 15/01/2022 07:49, Kjell Winblad via lldb-dev wrote:
Hi!
I'm implementing LLDB support for a new processor architecture that
the company I'm working for has created. The processor architecture
has a few emulated instructions. An emulated instruction works by
jumping to a specific address that contains the start of a block of
instructions that emulates the emulated instructions. The emulated
instructions execute with interrupts turned off to be treated as
atomic by the programmer. So an emulated instruction is similar to a
function call. However, the address that the instruction jumps to is
implicit and not specified by the programmer.
I'm facing a problem with the emulated instructions when implementing
source-level stepping (the LLDB next and step commands) for C code in
LLDB. LLDB uses hardware stepping to step through the address range
that makes up a source-level statement. This algorithm works fine
until the PC jumps to the start of the block that implements an
emulated instruction. Then LLDB stops because the PC exited the
address range for the source-level statement. This behavior is not
what we want. Instead, LLDB should ideally step through the emulation
instructions and continue until the current source-level statement has
been completed.
My questions are:
1. Is there currently any LLDB plugin functionality or special DWARF
debug information to handle the kind of emulated instructions that I
have described? All the code for the emulated instructions is within
the same address range that does not contain any other code.
2. If the answer to question 1 is no, do you have suggestions for
extending LLVM to support this kind of emulated instructions?
Best regards,
Kjell Winblad
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
