[lldb-dev] Source-level stepping with emulated instructions

[Greg Clayton via lldb-dev]

We just need to specify that the addresses for these emulated instruction address ranges have symbols and the type of these symbols are set to "eSymbolTypeTrampoline". We run into a similar case when you are stepping through the PLT entries for external functions. If your main binary has a "printf" symbol which is the trampoline to the actual "printf" function, the stepping logic will just continue through this code until it gets out of the address range.



> On Jan 14, 2022, at 10:49 PM, Kjell Winblad via lldb-dev <lldb-dev at lists.llvm.org> 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 at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev