https://bugs.llvm.org/show_bug.cgi?id=43442
Bug ID: 43442
Summary: LLDB installs Python modules to wrong path on some
systems
Product: lldb
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim
> Ingham via lldb-dev
> Sent: Tuesday, September 24, 2019 4:19 PM
> To: Nat!
> Cc: LLDB
> Subject: Re: [lldb-dev] Hiding trampoline functions from the backtrace, is
> it possible ?
>
>
>
> >
In a pure world, debugger users would use "step-in" when they meant to step in,
and step-over when they don't. However, it's actually pretty natural to say
"step-in" and then just keep hitting return, and expect the debugger to trace
through your code "doing the right thing".
When you've sto
I don't think that is right for "step-in". As you said above, in the classic
example of a trampoline: objc_msgSend you can't statically know the destination. So the
DWARF can't help resolve this; you would still need to do the work the lldb trampoline
classes do at runtime.
I was thinking
Right. If you watch the lazy binding that happens the first time a symbol is
called - at least on macOS - the loader does a lot of work, and calls various
standard library functions and helper functions in its own library that aren't
in any real sense trampolines. Actually, objc_msgSend can do
Nikita,
There was a lot of other stuff in that scripted_step.py beyond the plan class
itself. I didn't follow what that did altogether. But if I removed all that
stuff, and changed your plan slightly to not rely on the global TARGET and
START_ADDRESS (I attached my simplified version below),
