Re: [lldb-dev] Parallelizing loading of shared libraries
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, Jim Ingham wrote: > > We started out with the philosophy that lldb wouldn't touch any more > information in a shared library than we actually needed. So when a library > gets loaded we might need to read in and resolve its section list, but we > won't read in any symbols if we don't need to look at them. The idea was > that if you did "load a binary, and run it" until the binary stops for some > reason, we haven't done any unnecessary work. Similarly, if all the > breakpoints the user sets are scoped to a shared library then there's no > need for us to read any symbols for any other shared libraries. I think > that is a good goal, it allows the debugger to be used in special purpose > analysis tools w/o forcing it to pay costs that a more general purpose > debug session might require. > > I think it would be hard to convert all the usages of modules to from "do > something with a shared library" mode to "tell me you are interested in a > shared library and give me a callback" so that the module reading could be > parallelized on demand. But at the very least we need to allow a mode > where symbol reading is done lazily. > > The other concern is that lldb keeps the modules it reads in a global > cache, shared by all debuggers & targets. It is very possible that you > could have two targets or two debuggers each with one target that are > reading in shared libraries simultaneously, and adding them to the global > cache. In some of the uses that lldb has under Xcode this is actually very > common. So the task pool will have to be built up as things are added to > the global shared module cache, not at the level of individual targets > noticing the read-in of a shared library. > > Jim > > > > > On Apr 26, 2017, at 4:12 PM, Scott Smith via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > After a dealing with a bunch of microoptimizations, I'm back to > parallelizing loading of shared modules. My naive approach was to just > create a new thread per shared library. I have a feeling some users may > not like that; I think I read an email from someone who has thousands of > shared libraries. That's a lot of threads :-) > > > > The problem is loading a shared library can cause downstream > parallelization through TaskPool. I can't then also have the loading of a > shared library itself go through TaskPool, as that could cause a deadlock - > if all the worker threads are waiting on work that TaskPool needs to run on > a worker thread then nothing will happen. > > > > Three possible solutions: > > > > 1. Remove the notion of a single global TaskPool, but instead have a > static pool at each callsite that wants it. That way multiple paths into > the same code would share the same pool, but different places in the code > would have their own pool. > > > > 2. Change the wait code for TaskRunner to note whether it is already on > a TaskPool thread, and if so, spawn another one. However, I don't think > that fully solves the issue of having too many threads loading shared > libraries, as there is no guarantee the new worker would work on the > "deepest" work. I suppose each task would be annotated with depth, and the > work could be sorted in TaskPool though... > > > > 3. Leave a separate thread per shared library. > > > > Thoughts? > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parallelizing loading of shared libraries
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 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, Jim Ingham wrote: > > We started out with the philosophy that lldb wouldn't touch any more > information in a shared library than we actually needed. So when a library > gets loaded we might need to read in and resolve its section list, but we > won't read in any symbols if we don't need to look at them. The idea was > that if you did "load a binary, and run it" until the binary stops for some > reason, we haven't done any unnecessary work. Similarly, if all the > breakpoints the user sets are scoped to a shared library then there's no need > for us to read any symbols for any other shared libraries. I think that is a > good goal, it allows the debugger to be used in special purpose analysis > tools w/o forcing it to pay costs that a more general purpose debug session > might require. > > I think it would be hard to convert all the usages of modules to from "do > something with a shared library" mode to "tell me you are interested in a > shared library and give me a callback" so that the module reading could be > parallelized on demand. But at the very least we need to allow a mode where > symbol reading is done lazily. > > The other concern is that lldb keeps the modules it reads in a global cache, > shared by all debuggers & targets. It is very possible that you could have > two targets or two debuggers each with one target that are reading in shared > libraries simultaneously, and adding them to the global cache. In some of > the uses that lldb has under Xcode this is actually very common. So the task > pool will have to be built up as things are added to the global shared module > cache, not at the level of individual targets noticing the read-in of a > shared library. > > Jim > > > > > On Apr 26, 2017, at 4:12 PM, Scott Smith via lldb-dev > > wrote: > > > > After a dealing with a bunch of microoptimizations, I'm back to > > parallelizing loading of shared modules. My naive approach was to just > > create a new thread per shared library. I have a feeling some users may > > not like that; I think I read an email from someone who has thousands of > > shared libraries. That's a lot of threads :-) > > > > The problem is loading a shared library can cause downstream > > parallelization through TaskPool. I can't then also have the loading of a > > shared library itself go through TaskPool, as that could cause a deadlock - > > if all the worker threads are waiting on work that TaskPool needs to run on > > a worker thread then nothing will happen. > > > > Three possible solutions: > > > > 1. Remove the notion of a single global TaskPool, but instead have a static > > pool at each callsite that wants it. That way multiple paths into the same > > code would share the same pool, but different places in the code would have > > their own pool. > > > > 2. Change the wait code for TaskRunner to note whether it is already on a > > TaskPool thread, and if so, spawn another one. However, I don't think that > > fully solves the issue of having too many threads loading shared libraries, > > as there is no guarantee the new worker would work on the "deepest" work. > > I suppose each task would be annotated with depth, and the work could be > > sorted in TaskPool though... > > > > 3. Leave a separate thread per shared library. > > > > Thoughts? > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parallelizing loading of shared libraries
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 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 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, Jim Ingham wrote: >> >> We started out with the philosophy that lldb wouldn't touch any more >> information in a shared library than we actually needed. So when a library >> gets loaded we might need to read in and resolve its section list, but we >> won't read in any symbols if we don't need to look at them. The idea was >> that if you did "load a binary, and run it" until the binary stops for some >> reason, we haven't done any unnecessary work. Similarly, if all the >> breakpoints the user sets are scoped to a shared library then there's no >> need for us to read any symbols for any other shared libraries. I think >> that is a good goal, it allows the debugger to be used in special purpose >> analysis tools w/o forcing it to pay costs that a more general purpose debug >> session might require. >> >> I think it would be hard to convert all the usages of modules to from "do >> something with a shared library" mode to "tell me you are interested in a >> shared library and give me a callback" so that the module reading could be >> parallelized on demand. But at the very least we need to allow a mode where >> symbol reading is done lazily. >> >> The other concern is that lldb keeps the modules it reads in a global cache, >> shared by all debuggers & targets. It is very possible that you could have >> two targets or two debuggers each with one target that are reading in shared >> libraries simultaneously, and adding them to the global cache. In some of >> the uses that lldb has under Xcode this is actually very common. So the >> task pool will have to be built up as things are added to the global shared >> module cache, not at the level of individual targets noticing the read-in of >> a shared library. >> >> Jim >> >> >> >> > On Apr 26, 2017, at 4:12 PM, Scott Smith via lldb-dev >> > wrote: >> > >> > After a dealing with a bunch of microoptimizations, I'm back to >> > parallelizing loading of shared modules. My naive approach was to just >> > create a new thread per shared library. I have a feeling some users may >> > not like that; I think I read an email from someone who has thousands of >> > shared libraries. That's a lot of threads :-) >> > >> > The problem is loading a shared library can cause downstream >> > parallelization through TaskPool. I can't then also have the loading of a >> > shared library itself go through TaskPool, as that could cause a deadlock >> > - if all the worker threads are waiting on work that TaskPool needs to run >> > on a worker thread then nothing will happen. >> > >> > Three possible solutions: >> > >> > 1. Remove the notion of a single global TaskPool, but instead have a >> > static pool at each callsite that wants it. That way multiple paths into >> > the same code would share the same pool, but different places in the code >> > would have their own pool. >> > >> > 2. Change the wait code for TaskRunner to note whether it is already on a >> > TaskPool thread, and if so, spawn another one. However, I don't think >> > that fully solves the issue of having too many threads loading shared >> > libraries, as there is no guarantee the new worker would work on the >> > "deepest" work. I suppose each task would be annotated with depth, and >> > the work could be sorted in TaskPool though... >> > >> > 3. Leave a separate thread per shared library. >> > >> > Thoughts? >> > >> > ___ >> > lldb-dev mailing list >> > lldb-dev@lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parallelizing loading of shared libraries
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:51 AM, Pavel Labath wrote: > > 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 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 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, Jim Ingham wrote: >>> >>> We started out with the philosophy that lldb wouldn't touch any more >>> information in a shared library than we actually needed. So when a library >>> gets loaded we might need to read in and resolve its section list, but we >>> won't read in any symbols if we don't need to look at them. The idea was >>> that if you did "load a binary, and run it" until the binary stops for some >>> reason, we haven't done any unnecessary work. Similarly, if all the >>> breakpoints the user sets are scoped to a shared library then there's no >>> need for us to read any symbols for any other shared libraries. I think >>> that is a good goal, it allows the debugger to be used in special purpose >>> analysis tools w/o forcing it to pay costs that a more general purpose >>> debug session might require. >>> >>> I think it would be hard to convert all the usages of modules to from "do >>> something with a shared library" mode to "tell me you are interested in a >>> shared library and give me a callback" so that the module reading could be >>> parallelized on demand. But at the very least we need to allow a mode >>> where symbol reading is done lazily. >>> >>> The other concern is that lldb keeps the modules it reads in a global >>> cache, shared by all debuggers & targets. It is very possible that you >>> could have two targets or two debuggers each with one target that are >>> reading in shared libraries simultaneously, and adding them to the global >>> cache. In some of the uses that lldb has under Xcode this is actually very >>> common. So the task pool will have to be built up as things are added to >>> the global shared module cache, not at the level of individual targets >>> noticing the read-in of a shared library. >>> >>> Jim >>> >>> >>> On Apr 26, 2017, at 4:12 PM, Scott Smith via lldb-dev wrote: After a dealing with a bunch of microoptimizations, I'm back to parallelizing loading of shared modules. My naive approach was to just create a new thread per shared library. I have a feeling some users may not like that; I think I read an email from someone who has thousands of shared libraries. That's a lot of threads :-) The problem is loading a shared library can cause downstream parallelization through TaskPool. I can't then also have the loading of a shared library itself go through TaskPool, as that could cause a deadlock - if all the worker threads are waiting on work that TaskPool needs to run on a worker thread then nothing will happen. Three possible solutions: 1. Remove the notion of a single global TaskPool, but instead have a static pool at each callsite that wants it. That way multiple paths into the same code would share the same pool, but different places in the code would have their own pool. 2. Change the wait code for TaskRunner to note whether it is already on a TaskPool thread, and if so, spawn another one. However, I don't think that fully solves the issue of having too many threads loading shared libraries, as there is no guarantee the new worker would work on the "deepest" work. I suppose each task would be annotated with depth, and the work could be sorted in TaskPool though... 3. Leave a separate thread per shared library. Thoughts? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >>> >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _
Re: [lldb-dev] Parallelizing loading of shared libraries
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-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:51 AM, Pavel Labath wrote: > > > > 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 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 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, Jim Ingham wrote: > >>> > >>> We started out with the philosophy that lldb wouldn't touch any more > information in a shared library than we actually needed. So when a library > gets loaded we might need to read in and resolve its section list, but we > won't read in any symbols if we don't need to look at them. The idea was > that if you did "load a binary, and run it" until the binary stops for some > reason, we haven't done any unnecessary work. Similarly, if all the > breakpoints the user sets are scoped to a shared library then there's no > need for us to read any symbols for any other shared libraries. I think > that is a good goal, it allows the debugger to be used in special purpose > analysis tools w/o forcing it to pay costs that a more general purpose > debug session might require. > >>> > >>> I think it would be hard to convert all the usages of modules to from > "do something with a shared library" mode to "tell me you are interested in > a shared library and give me a callback" so that the module reading could > be parallelized on demand. But at the very least we need to allow a mode > where symbol reading is done lazily. > >>> > >>> The other concern is that lldb keeps the modules it reads in a global > cache, shared by all debuggers & targets. It is very possible that you > could have two targets or two debuggers each with one target that are > reading in shared libraries simultaneously, and adding them to the global > cache. In some of the uses that lldb has under Xcode this is actually very > common. So the task pool will have to be built up as things are added to > the global shared module cache, not at the level of individual targets > noticing the read-in of a shared library. > >>> > >>> Jim > >>> > >>> > >>> > On Apr 26, 2017, at 4:12 PM, Scott Smith via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > After a dealing with a bunch of microoptimizations, I'm back to > parallelizing loading of shared modules. My naive approach was to just > create a new thread per shared library. I have a feeling some users may > not like that; I think I read an email from someone who has thousands of > shared libraries. That's a lot of threads :-) > > The problem is loading a shared library can cause downstream > parallelization through TaskPool. I can't then also have the loading of a > shared library itself go through TaskPool, as that could cause a deadlock - > if all the worker threads are waiting on work that TaskPool needs to run on > a worker thread then nothing will happen. > > Three possible solutions: > > 1. Remove the notion of a single global TaskPool, but instead have a > static pool at each callsite that wants it. That way multiple paths into > the same code would share the same pool, but different places in the code > would have their own pool. > > 2. Change the wait code for TaskRunner to note whether it is already > on a TaskPool thread, and if so, spawn another one. However, I don't think > that fully solves the issue of having too many threads loading shared > libraries, as there is no guarantee the new worker would work on the > "deepest" work. I suppose each task would be annotated with depth, and the > work could be sorted in TaskPool though... > > 3. Leave a separate thread per shared library. > > Thoughts? > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >>> > >>> > >> > >> ___
Re: [lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8
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 (as of today 7.99.70) with
> the GNU toolchain.
>
> Once the new one setup will be in operation, I will upgrade the old one
> to 7.99.70 (& retain the same name), switch the to the staging cluster
> http://lab.llvm.org:8014/ and turn on execution of tests.
>
> Am I right that in order to turn tests I need to switch "runTest=False"
> to "runTest=True" in buildbot/osuosl/master/config/builders.py?
>
>
> Affirmative.
>
> As you are using the "scripted" build factory, you'll also need to
> create a test_cfg.json in your scripts folder on the build slave, which
> describes the kind of tests you want to run:
> For example, the linux build bot has this in the file:
> {
> "test1": "local,clang-3.5,i386",
> "test2": "local,clang-3.5,x86_64",
> "test3": "local,totclang,i386",
> "test4": "local,totclang,x86_64",
> "test5": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,i386",
> "test6": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,x86_64"
> }
> but a single test line would probably be enough for you.
> Then, the master will invoke a script "test.sh" with the test config
> argument: (e.g., ./test.sh local,clang-3.5,i386) and your script should
> run the tests.
>
> let me know if you run into problems,
> pl
lldb-amd64-ninja-netbsd8 [kernel ABI version 7.99.70] is up and running
lldb-amd64-ninja-netbsd7 has been upgraded to 7.99.70 and restarted
I switched the old machine to the staging buildfarm, set runTest=True in
buildbot/osuosl/master/config/builders.py and added the following
test_cfg.json:
$ cat ./build/build/test_cfg.json
{
"test1": "local,gcc,x86_64",
}
As of now it does not attempt to run the regression tests. Perhaps we
need to restart buildmaster configuration? I will ask Galina for it.
signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
