[PATCH] D42582: [lldb][PPC64] Fixed step-in stopping in the wrong line
Leandro via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 15 07:36:16 PST 2018
Is there any update on this?
Are my assumptions from the previous message correct?
On Tue, Feb 6, 2018 at 9: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?
> For ELF files, this seems to be done in ObjectFileELF.cpp,
> 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?
> - 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.
>> > 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...
More information about the llvm-commits