<div dir="ltr"><div>Greg, Jim,<br><br></div><div>Marking the global entry point as a trampoline to the local entry point didn't work.<br><br></div><div>The problem is that symbol information starts conflicting with debug information (DWARF).<br><br></div><div></div><div>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.<br></div><div>(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)<br><br></div><div>When it reaches the "step past prologue" part, it gets the symbol context, that populates the "function" field with information from DWARF.<br>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.<br></div><div><br>In this part, ELF symbol information is used only if LLDB is unable to retrieve debug information.<br></div><div><br><br></div><div>Do you know a good solution for this issue?<br><br></div><div>Or would it be better to go back to the architecture plugin approach?<br></div><div><br></div><div>Thanks,<br></div>Leandro<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 15, 2018 at 2:12 PM, Greg Clayton <span dir="ltr"><<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><span class=""><br><blockquote type="cite"><div>On Feb 6, 2018, at 3:31 AM, Leandro <<a href="mailto:leandro.lupori@gmail.com" target="_blank">leandro.lupori@gmail.com</a>> wrote:</div><br class="m_9058416841443600749Apple-interchange-newline"><div><div dir="ltr"><div><div><div>Ok, so we should mark the global entry point as a trampoline by setting the symbol type to lldb::eSymbolTypeTrampoline, right?<br></div></div></div></div></div></blockquote><div><br></div></span>If there isn't ever anything useful to debug in the global entry point, then yes.</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><div><div><br></div>For ELF files, this seems to be done in ObjectFileELF.cpp, ParseTrampolineSymbols.<br></div></div></div></div></blockquote><div><br></div></span>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().</div><div><br></div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div>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?<br></div>Maybe a new conditional arch-specific step in ObjectFileELF::ParseSymbols, similar to those of ARM and MIPS?<br></div></div></blockquote><div><br></div></span>Yes you are on the right track. Any info you can glean from the symbol itself can be parsed in ObjectFileELF::<wbr>ParseSymbols().</div><span class=""><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">- Leandro<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 5, 2018 at 4:03 PM, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<span class="m_9058416841443600749HOEnZb"><font color="#888888"><br>
Jim<br>
</font></span><div class="m_9058416841443600749HOEnZb"><div class="m_9058416841443600749h5"><br>
<br>
> On Feb 3, 2018, at 3:38 AM, Leandro Lupori via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br>
><br>
> luporl added a comment.<br>
><br>
>> 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?<br>
><br>
> You can look at it as part of the prologue. You'll want to debug it only if you want to debug the prologue.<br>
><br>
>> Does a global entry point always forward on to a local entry point?<br>
><br>
> When there are 2 entry points, yes, the global entry point always forwards to the local entry point.<br>
><br>
>> Does the local entry point always exists and is it the only thing that can be debugged?<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
><br>
> <a href="https://reviews.llvm.org/D42582" rel="noreferrer" target="_blank">https://reviews.llvm.org/D4258<wbr>2</a><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>
</div></blockquote></div><br></span></div></blockquote></div><br></div>