On 24.04.2017 11:42, Pavel Labath wrote:
>
>
> On 22 April 2017 at 23:57, Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
>
> Hello,
>
> I'm in process of attaching new build machine lldb-amd64-ninja-netbsd8.
>
> It will run prerelease of NetBSD/amd64 8.0 (a
Hmm, turns out I was wrong about delayed symbol loading not working under
Linux. I've added timings to the review.
On Thu, Apr 27, 2017 at 11:12 AM, Jim Ingham wrote:
> Interesting. Do you have to catch this information as the JIT modules get
> loaded, or can you recover the data after-the-fac
Interesting. Do you have to catch this information as the JIT modules get
loaded, or can you recover the data after-the-fact? For most uses, I don't
think you need to track JIT modules as they are loaded, but it would be good
enough to refresh the list on stop.
Jim
> On Apr 27, 2017, at 10:
It's the gdb jit interface breakpoint. I don't think there is a good
way to scope that to a library, as that symbol can be anywhere...
On 27 April 2017 at 18:35, Jim Ingham via lldb-dev
wrote:
> Somebody is probably setting an internal breakpoint for some purpose w/o
> scoping it to the shared
Somebody is probably setting an internal breakpoint for some purpose w/o
scoping it to the shared library it's to be found in. Either that or somebody
has broken lazy loading altogether. But that's not intended behavior.
Jim
> On Apr 27, 2017, at 7:02 AM, Scott Smith wrote:
>
> So as it tur
So as it turns out, at least on my platform (Ubuntu 14.04), the symbols are
loaded regardless. I changed my test so:
1. main() just returns right away
2. cmdline is: lldb -b -o run /path/to/my/binary
and it takes the same amount of time as setting a breakpoint.
On Wed, Apr 26, 2017 at 5:00 PM, J
