Thank you Pavel and Jim for very helpful answers. > Note, the “no debug info" part is not a strict requirement, > since lldb also has controls for “shared libraries we never > stop in when stepping” and “name regular expressions > for functions we don’t stop in”. At present, those controls > are just for user-specification. But if you find you need to > do something more programmatic, you can easily add > another “don’t stop in me” check specific to your > architecture.
I have done some quick experiments with "target.process.thread.step-avoid-regexp" and it seems like I can use it to get the behavior we want so adding a “don’t stop in me” check specific to our architecture seems like a good solution for us. Best regards, Kjell On Tue, 18 Jan 2022 at 19:42, Jim Ingham via lldb-dev <lldb-dev@lists.llvm.org> wrote: > > I think that description was a bit too much inside baseball…. > > Every time lldb stops outside a stepping range while stepping, it invokes a > set of “should stop here” agents to determine what to do next. If any of > those agents think we should NOT stop here, they are expected to produce a > set of instructions (i.e. a ThreadPlan) that drive the thread back to the > original code. > > The “we stopped in a function with no debug information, step back out” > behavior of lldb is implemented this way. So if you can make your emulated > instruction regions look like function calls w/o debug info, you would get > this behavior for free. But the mechanism is pretty flexible, and you just > need to leave yourself enough information to (a) know you are in one of your > regions and (b) how to drive the debugger to get back to the code that > invoked this emulated instruction, in order to get lldb’s “should stop here” > machinery to do what you want. > > Jim > > > On Jan 18, 2022, at 10:28 AM, Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > > > On Jan 16, 2022, at 11:23 PM, Pavel Labath <pa...@labath.sk> wrote: > > 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...) > > > Pavel is right, if these blobs look like function calls with no debug > information, then lldb won’t stop in them by default. Note, the “no debug > info" part is not a strict requirement, since lldb also has controls for > “shared libraries we never stop in when stepping” and “name regular > expressions for functions we don’t stop in”. At present, those controls are > just for user-specification. But if you find you need to do something more > programmatic, you can easily add another “don’t stop in me” check specific to > your architecture. > > All this will work pretty transparently if the unwinder is able to tell us > how to get out of the function and back to it’s caller. But even if that’s > not the case, the “should stop here” mechanism in lldb works by at a lower > level by having the agent saying we should NOT stop here return a ThreadPlan > telling us how to get to the caller frame. For a function call, you get the > step out plan for free. But that’s not a requirement, your emulated > instruction region doesn’t strictly need to be a function call, provided you > know how to produce a thread plan that will step out of it. > > Jim > > > > 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 > > > _______________________________________________ > 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
