<br><br><div class="gmail_quote">On Thu Dec 04 2014 at 2:29:45 PM Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Dec 4, 2014, at 12:27 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> I started working on implementing a DynamicLoader plugin.<br>
><br>
> While it's indeed quite simple, I still have some questions about why it's necessary to make shared library load/unloading work.<br>
><br>
> 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<br>
><br>
> if (event is a module load)<br>
>     dynamic_loader-><u></u>NotifyModuleLoad(module);<br>
> else if (event is a module unload)<br>
>     dynamic_loader-><u></u>NotifyModuleUnload(module);<br>
><br>
> 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()<u></u>.<br>
><br>
> 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().<br>
<br>
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.<br>
<br>
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?<br></blockquote><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> 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".<br>
<br>
Indeed.<br>
><br>
> Just to clarify some terminology, are "shared library", "module", and "image" here the same thing?<br>
<br>
Yes.<br>
<br>
> Why would you have a shared library that is loaded but not in the target?<br>
<br>
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:<br>
<br>
(lldb) image list<br>
/tmp/a.out<br>
/usr/lib/libc.dylib<br>
/usr/lib/libxml2.dylib<br>
<br>
But when you run you specified DYLD_LIBRARY_PATH=/tmp/my_<u></u>dylibs in the environement so when you actually attach to "a.out" you really have a different set of shared libraries:<br>
<br>
(lldb) image list<br>
/tmp/a.out<br>
/tmp/my_dylibs/libc.dylib<br>
/usr/lib/libxml2.dylib<br>
<br>
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.<br>
<br>
<br>
>  Where else would it be?<br>
<br>
See above.<br>
<br>
>  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?<br>
<br>
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.<br></blockquote><div><br></div><div>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?</div></div>