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
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
> wrote:
>
>
>
> On Jan 16, 2022, at 11:23 PM, Pavel Labath 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 t
