I found this bug from a year ago (
https://llvm.org/bugs/show_bug.cgi?id=17384) that explains everything.
Greg, 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?
On Wed, Mar 11, 2015 at 12:47 PM, Greg Clayt
> On Mar 11, 2015, at 11:09 AM, Chaoren Lin wrote:
>
> 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.
We need to modify the Ob
> On Mar 11, 2015, at 11:09 AM, Chaoren Lin wrote:
>
> 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.
>
> "image show-unwind -
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.
"image show-unwind -a $pc" in the subroutine shows no unwind data.
Hi guys, sorry for not seeing this thread yesterday.
lldb should be able to handle this function, if and only if it knows the start
address for the function/symbol. The assembly instruction profiler can do the
right thing with an instruction sequence like this.
The first thing to do is
(l
After some more debugging, I no longer think it's related to the syscall.
The subroutine that invokes the syscall has a strange prologue (see below)
which results in a return address stored at ebp+12 instead of ebp+4, which
seems to be what LLDB uses to determine if a frame is valid. Is there some
