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@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@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
