Re: [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 
>  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

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

[Kjell Winblad via lldb-dev]

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

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

[Jim Ingham via lldb-dev]

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

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

[Pavel Labath via lldb-dev]

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