[PATCH] D42582: [lldb][PPC64] Fixed step-in stopping in the wrong line

[Jim Ingham via llvm-commits]

The way trampolines work in lldb is that they mark places in the debugee where you want to stop, but somebody (generally the DynamicLoader plugin) might provide a "step through trampoline" plan to go somewhere you do want to go.

You could do that: the plan would just move forward to the local entry point.  Then when we stepped onto the global entry point, the step through would move you to the local one and then everything would match up.  This is just the simple ThreadPlanRunToAddress, you wouldn't have to do anything special. 

Providing step through trampolines is the job of the dynamic loader plugin at present.  This isn't really right for the DynamicLoader, however.  It's really architecture specific, not loader specific.  But we could query the ABI to see if it provides step through as well.  This is wired up in done in: ThreadPlanStepThrough::LookForPlanToStepThroughFromCurrentPC.  You could try sticking it into the ELF dynamic loader first - since that's already wired up - and see if this fixes the problem.  If it does, we can think about where better that this should go.

Jim


> On Feb 19, 2018, at 10:02 AM, Leandro <leandro.lupori at gmail.com> wrote:
> 
> Greg, Jim,
> 
> Marking the global entry point as a trampoline to the local entry point didn't work.
> 
> The problem is that symbol information starts conflicting with debug information (DWARF).
> 
> For instance, when trying to step into a function with two entry points, from a local call site, LLDB will eventually call ThreadStepInRange::ShouldStop() to handle it.
> (ThreadPlanStepThrough won't be used in this case, because the local entry point is used instead of the global entry point/trampoline, that gets skipped by the call)
> 
> When it reaches the "step past prologue" part, it gets the symbol context, that populates the "function" field with information from DWARF.
> But in DWARF info, the function start address is the global entry point, which won't match the current PC (local entry point), which bring us back to the original problem.
> 
> In this part, ELF symbol information is used only if LLDB is unable to retrieve debug information.
> 
> 
> Do you know a good solution for this issue?
> 
> Or would it be better to go back to the architecture plugin approach?
> 
> Thanks,
> Leandro
> 
> On Thu, Feb 15, 2018 at 2:12 PM, Greg Clayton <clayborg at gmail.com> wrote:
> 
> 
>> On Feb 6, 2018, at 3:31 AM, Leandro <leandro.lupori at gmail.com> wrote:
>> 
>> Ok, so we should mark the global entry point as a trampoline by setting the symbol type to lldb::eSymbolTypeTrampoline, right?
> 
> If there isn't ever anything useful to debug in the global entry point, then yes.
> 
>> 
>> For ELF files, this seems to be done in ObjectFileELF.cpp, ParseTrampolineSymbols.
> 
> It can also be during the normal symbol table parsing if you know that a symbol is a global entry point for PPC. You don't have to wait to set the symbol table until ParseTrampolineSymbols, so feel free to set the "symbol_type" correctly in ObjectFileELF::ParseSymbols().
> 
> 
>> But as this change will be specific to ppc64, and the local entry point is encoded in the "other" field of the function symbol itself, where would be the best place to insert this new code?
>> Maybe a new conditional arch-specific step in ObjectFileELF::ParseSymbols, similar to those of ARM and MIPS?
> 
> Yes you are on the right track. Any info you can glean from the symbol itself can be parsed in ObjectFileELF::ParseSymbols().
> 
>> 
>> - Leandro
>> 
>> On Mon, Feb 5, 2018 at 4:03 PM, Jim Ingham <jingham at apple.com> wrote:
>> As long as the prologue computation is done correctly we won't ever stop at the global entry point separately from the local one.  The will - after prologue skipping - resolve to the same address, and both stepping and breakpoint setting skip to the prologue unless you explicitly tell them not to.  So while I see the formal niceness of calling this a prologue, I don't think it is necessary.
>> 
>> Jim
>> 
>> 
>> > On Feb 3, 2018, at 3:38 AM, Leandro Lupori via Phabricator <reviews at reviews.llvm.org> wrote:
>> >
>> > luporl added a comment.
>> >
>> >> if you have a global entry point, is there ever any reason to stop at these? Is there anything you can debug in the global entry point?
>> >
>> > You can look at it as part of the prologue. You'll want to debug it only if you want to debug the prologue.
>> >
>> >> Does a global entry point always forward on to a local entry point?
>> >
>> > When there are 2 entry points, yes, the global entry point always forwards to the local entry point.
>> >
>> >> Does the local entry point always exists and is it the only thing that can be debugged?
>> >
>> > Some functions may have only one entry point, be it local or global. If you don't want to debug the prologue, you will actually want to skip some bytes past the local entry point, to get past the prologue, to code that can be debugged.
>> >
>> > Overall you can look at the local entry point as a kind of optimization, that enables a local call to skip part of the prologue.
>> >
>> >
>> > https://reviews.llvm.org/D42582
>> >
>> >
>> >
>> 
>> 
> 
>