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

[Leandro via llvm-commits]

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
>> >
>> >
>> >
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180219/d7dc7681/attachment.html>