On Thu Dec 04 2014 at 2:29:45 PM Greg Clayton <gclay...@apple.com> wrote:
> > > On Dec 4, 2014, at 12:27 PM, Zachary Turner <ztur...@google.com> wrote: > > > > I started working on implementing a DynamicLoader plugin. > > > > While it's indeed quite simple, I still have some questions about why > it's necessary to make shared library load/unloading work. > > > > I do understand the use case for other platforms, because there is a > non-trivial amount of work required to detect shared library loading / > unloading. On Windows however, there is no work involved because the OS > tells us at every occurrence of a shared library load or unload. As a > result, my DynamicLoader implementation basically boils down to some code > like this in my process plugin > > > > if (event is a module load) > > dynamic_loader->NotifyModuleLoad(module); > > else if (event is a module unload) > > dynamic_loader->NotifyModuleUnload(module); > > > > In each of these two methods, all I do is construct an empty ModuleList, > add a single item to it, set the load address, and call > GetTarget().ModulesDidLoad() or GetTarget().ModulesDidUnload(). > > > > So either way I'm calling ModulesDidLoad() / ModulesDidUnload() > directly, it's just am I having the Process plugin tell the DynamicLoader > to do it, or am I having the process do it itself. Whichever one does it > though, it's the same few lines of code to prepare the call to > ModulesDidLoad(). > > That is indeed simple and if you have all the info you need in the message > that is sent to the data to the handle, then it doesn't make sense to do > this in the dynamic loader. For us, we can use the same dynamic loader > plug-in with different Process subclasses since it just uses the process to > find a symbol and read data via memory reads. So our dynamic loader will > work on core files with ProcessMachCore and it also works with > ProcessGDBRemote. In your case, you are getting messages straight from your > process runner via the OS which is quite different than any other platform, > so don't change anything, but you can continue to do what you do by > directly doing the load/unload from the process plug-in and have your > DynamicLoaderWindows just not do anything. > > One thing you might actually need to do in the DynamicLoaderWindows is > find out all the shared libraries that are loaded when you attach to a > process. When you attach to a running process in windows, does it give you > a bunch of callbacks for each shared library that is already loaded? Just > like when you are running and a shared library loads/unloads? Or must you > discover them in a different way? > That's a good question and it's actually still an unknown. There's still a bit more work I need to do before being able to attach to a process. It might give me a module load notification for each existing module right when I load, and I might have to enumerate them. Even if I have to enumerate them, the code to do that is pretty simple. But it might make sense to put that code in the DynamicLoader::DidAttach method anyway. For that matter, it might also make sense to add the main executable's module in DynamicLoader::DidLaunch, if nothing else for consistency. But modules that load or unload while the debugger is connected seem to be a natural fit to just calling ModulesDidLoad. > > > > > One more question: You said this: "the MacOSX version finds the global > list of shared libraries that are loaded, iterates through them, seaches > for any modules that are in the target, removes any images from the target > that aren't loaded, then sets the section load address for all sections in > all modules to the correct value". > > Indeed. > > > > Just to clarify some terminology, are "shared library", "module", and > "image" here the same thing? > > Yes. > > > Why would you have a shared library that is loaded but not in the target? > > You wouldn't, but you might have said "file a.out" on the command line, > and from just inspecting the "a.out" mach-o file it added a bunch of > modules to your target. Before you run you would have: > > (lldb) image list > /tmp/a.out > /usr/lib/libc.dylib > /usr/lib/libxml2.dylib > > But when you run you specified DYLD_LIBRARY_PATH=/tmp/my_dylibs in the > environement so when you actually attach to "a.out" you really have a > different set of shared libraries: > > (lldb) image list > /tmp/a.out > /tmp/my_dylibs/libc.dylib > /usr/lib/libxml2.dylib > > We we start out with a target that contains the first three images, but > when we run and get our first batch of shared library loaded notifications > we look for "/tmp/a.out" and leave it because it is correct and set its > load location, we remove the "/tmp/lib/libc.dylib" from the image list in > the target and add the "/tmp/my_dylibs/libc.dylib" and then set its load > address, and then we look for "/usr/lib/libxml2.dylib" and keep it because > it is correct and set its load addresses. > > > > Where else would it be? > > See above. > > > As for setting the section load address for all sections, it sounds > like this is the same as just calling module->SetModuleLoadAddress() to the > load address of the entire shared library. Is this correct? > > If your system always loads all sections by sliding them all by constant > amounts, then yes. On MacOSX, all shared libraries in the shared cache will > have all their sections moved separately. So we need to load add sections > to completely different addresses (we don't just add a constant slide to > all of them like module->SetModuleLoadAddress() does). Some sections aren't > loaded sometimes (like the "__LINKEDIT" section isn't always loaded for our > kernel). So you need to do what you need to do to load things correctly on > your system. > Makes sense, thanks. Last question. When a module loads the notification I get contains the load address. So I call module->SetLoadAddress(x), and then ModulesDidLoad, at some point in the future I'm going to get a module unloaded event with the only parameter being x. It doesn't seem there's an easy way for me to find the ModuleSP in the target given only this value. Do I need to just keep my own map in the DynamicLoader or in the Process plugin?
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
