[lldb-dev] [RFC] Extend ObjectFile interface.

[Greg Clayton]

A few quick questions: 

Regaring the:

  virtual lldb_private::Address
  GetImageInfoAddress () { return Address(); }

Is this value not in any symbol in the symbol table in the ELF file? If it is a symbol, and the ELF plug-in could classify the symbol type as a special symbol type (see Symbol.h), then could we do it this way?



On Jan 12, 2011, at 11:07 AM, Greg Clayton wrote:

> 
> On Jan 11, 2011, at 8:17 PM, Stephen Wilson wrote:
> 
>> 
>> *,
>> 
>> I have been prototyping a DynamicLoader plugin for the Linux platform.
>> Current state of the effort is available here:
>> 
>>  https://github.com/eightcien/lldb/tree/lldb-linux
>> 
>> 
>> On ELF platforms there is a "rendezvous" structure in a processes
>> address space populated by the runtime linker for use by debuggers.
>> This structure provides the address of a function which is called by the
>> linker each time a shared object is loaded and unloaded (thus a
>> breakpoint at that address will let a debugger intercept such events), a
>> list of entries describing the currently loaded shared objects, plus a
>> few other things.
>> 
>> In order to locate this structure one must interrogate the object file
>> for the process.  The location of this rendezvous is provided by a
>> DT_DEBUG entry in the processes .dynamic section.  The actual address
>> must be reaped by looking at the loaded .dynamic section contents of the
>> process.
>> 
>> The first proposal is to add the following method to ObjectFile, which
>> allows us to locate the needed information:
>> 
>>   //------------------------------------------------------------------
>>   /// Similar to Process::GetImageInfoAddress().
>>   ///
>>   /// Some platforms embed auxiliary structures useful to debuggers in the
>>   /// address space of the inferior process.  This method returns the address
>>   /// of such a structure if the information can be resolved via entries in
>>   /// the object file.  ELF, for example, provides a means to hook into the
>>   /// runtime linker so that a debugger may monitor the loading and unloading
>>   /// of shared libraries.
>>   ///
>>   /// @return 
>>   ///     The address of any auxiliary tables, or an invalid address if this
>>   ///     object file format does not support or contain such information.
>>   virtual lldb_private::Address
>>   GetImageInfoAddress () { return Address(); }
>> 
>> In my prototype the above method is implemented by ObjectFileELF, and
>> Process::GetImageInfoAddress in turn uses this information.
>> 
>> I use an Address object instead of an lldb::addr_t as it is slightly
>> more generic, and perhaps more useful, to represent the info as a
>> "section load address + offset".
> 
> Yes, this looks fine. The "Address" is the right thing to use since it can point you back to your module.
> 
> A quick note to everyone: if you have an Address can you get the module from which is comes which can then get your to your object and symbol files:
> 
> Address addr (...);
> Module *module = addr.GetModule();
> // Check the module in case "addr" was not section/offset (the section might be NULL)
> if (module)
> {
>    ObjectFile *objfile = module->GetObjectFile();
>    SymbolVendor*symbols = module->GetSymbolVendor();
>    ...
> }
> 
> Since addresses are stored as section offset, when shared libraries get loaded, the dynamic loader plug-ins tell the target where each section got loaded. Then we can resolve addresses as needed. 
> 
> For example, if you have a PC value 0x100020 that you got from a register in a thread, you can then resolve it:
> 
> addr_t pc = 0x100020;
> Address pc_addr;
> if (thread.GetProcess().GetTarget().GetSectionLoadList().ResolveLoadAddress(pc, pc_addr))
> {
>    // The address was successfully resolved and now contains a "Section *" that can point
>    // you to the Module/ObjectFile/Symbols...
> }
> 
>> 
>> 
>> The second bit is to provide the DynamicLoader plugin with a method to
>> synchronize with the runtime linker.  A simple strategy is to set a
>> breakpoint on the entry address for the executable and to parse the
>> rendezvous structure after the linker has had a chance to populate it.
>> Hence the following addition:
>> 
>>   //------------------------------------------------------------------
>>   /// Returns the virtual address of the entry point for this object 
>>   /// file.
>>   ///
>>   /// @return
>>   ///     The virtual address of the entry point or 
>>   ///     LLDB_INVALID_ADDRESS if an entry point is not defined.
>>   //------------------------------------------------------------------
>>   virtual lldb::addr_t
>>   GetEntryPoint () const { return LLDB_INVALID_ADDRESS; }
>> 
>> 
>> The above two methods are enough to get a minimal DynamicLoader plugin
>> functioning on Linux.  I would very much appreciate any
>> feedback/comments on the above.
> 
> I would rather see this added as:
> 
>   virtual Address
>   GetEntryPoint () const { return Address(); }
> 
> So that you know what module the entry point came from. The linux dynamic loader would then just know that the file and load addresses for a linux executable (not shared library, just executable files) are the same (is this true? Do the virtual addresses in the ELF file for an executable never change?) and it could get the entry point as an addr_t by doing:
> 
> 
> ModuleSP exe_module_sp (target->GetExecutableModule ());
> if (exe_module_sp)
> {
> 	ObjectFile *exe_objfile = exe_module_sp->GetObjectFile();
> 	if (exe_objfile)
> 	{
> 		Address entry_point (exe_objfile->GetEntryPoint());
> 		addr_t entry_point_load_addr = entry_point.GetFileAddress();
> 	}
> }
> 
> 
> The other thing you might want to do, is in the linix dynamic loader plug-in, if you know that the executable is always at the same address as the virtual addresses in the file, you can automatically register the load address of the sections as soon as you construct the DynamicLoaderLinux object. Because when setting a breakoint, it will eventually turn into a section/offset breakpoint and the breakpoint won't set itself until the section gets loaded.
> 
> Let me know if you have any questions on this.
> 
> Greg Clayton
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev