<div dir="ltr">I found this bug from a year ago (<a href="https://llvm.org/bugs/show_bug.cgi?id=17384">https://llvm.org/bugs/show_bug.cgi?id=17384</a>) that explains everything.<div><br></div><div>Greg, <span style="color:rgb(0,0,0);white-space:pre-wrap">ObjectFileELF::CreateMemoryInstance is no longer just a stub. Do you know if linux-gate.so is read but not parsed, or still not read at all?</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 11, 2015 at 12:47 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Mar 11, 2015, at 11:09 AM, Chaoren Lin <<a href="mailto:chaorenl@google.com">chaorenl@google.com</a>> wrote:<br>
><br>
</span><span class="">> The problem is not the __read function, but a subroutine that the __read function calls. GDB shows it as __kernel_vsyscall, but LLDB doesn't have a name for it, I don't think LLDB even considers it a function.<br>
<br>
</span>We need to modify the ObjectFileELF::ParseSymtab() to then create synthetic symbols for these things. You will need to dig around in the ELF spec and figure out how to reconstruct symbols for such things. If you do this, then everything should work. The ObjectFileMachO pulls all sorts of tricks to make sure that we create functions for everything the object file knows about and should be considered as a block of code and ObjectFileELF should do the same.<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
<br>
<br>
</font></span></blockquote></div><br></div>