[lldb-dev] Update on Linux work.

[Greg Clayton]

On Jul 21, 2010, at 3:53 PM, Stephen Wilson wrote:

> Hi Greg,
> 
> Greg Clayton <gclayton at apple.com> writes:
>>> - We need to make the dwarf debug section names (as defined
>>>  SymbolFileDwarf.cpp) selectable by platform.  I implemented a simple
>>>  macro hack to work around this for now.  A better solution might be
>>>  to have a header #define the section names.  Any suggestions
>>>  appreciated:
>>> 
>>>    http://github.com/ice799/lldb/commit/284c444cae1feedc39f48ffed1265abf3fea291c
>> 
>> Sections already contain a "SectionType" enumeration. I _just_ added
>> new definitions for the DWARF section types (r109041) and added the
>> ability to search a SectionList by SectionType (r109040).
>> 
>> So if you make the ELF ObjectFile parser correctly set the SectionType
>> for DWARF sections correctly, you can use the new function I just
>> added:
>> 
>> lldb::SectionSP SectionList::FindSectionByType (lldb::SectionType
>> sect_type, uint32_t start_idx) const;
>> 
>> This will allow us to insulate the LLDB core logic from having to know
>> the the naming conventions imposed by the object file format (MachO
>> and ELF). I will take care of making the changes for the MachO
>> ObjectFile parser to set the section types correctly and also modify
>> the DWARF plug-in to search for the sections by type.
> 
> This is great.  Will update the ELF reader at the first opportunity. 

I just did the Mach and ELF plugins: Committed revision 109054. This patch also fixes the DWARF plugin to get any needed DWARF sections by SectionType. So everything should be working from the DWARF perpsective now.


> 
>>> - There is a good bit of sharable code in the MacOSX-User plugin with
>>>  respect to RegisterContext specializations.  Please find attached two
>>>  files which provide a partial x86_64 RegisterContext specialization.
>>>  The idea is to introduce
>>>  lldb/include/Target/X86/RegisterContext_x86_64.h so all all plugins
>>>  can share common definitions and code.  Again, any thoughts or
>>>  suggestions on this approach appreciated!
>> 
>> This sounds like a nice idea, though I don't know how well this would
>> work in practice. The idea behind the register context is to allow
>> each plug-in to define its own register numbers as they make sense for
>> the platform. 
> 
> OK.  I misinterpreted the intended semantics for this class.  My
> impression was that we could have a base set of "known" registers that
> would be translated into the internal encoding via a call to
> ConvertRegisterKindToRegisterNumber (which would return
> LLDB_INVALID_REGNUM if not available).  Finally, to support additional
> pseudo-register sets (like Mach exception state) the platform plugin
> would provide additional RegisterSet's beyond that provided by the base
> class.
> 
> But from what you write below I see there is more to consider :)
> 
>> The number of available registers for x86_64 might be
>> different between Darwin and Linux. The register numbers can always be
>> set by each plug-in to match as closely to the native OS register
>> structures as possible to make the creation of the
>> ReadRegister/WriteRegister very easy to code for that platform. For
>> example the Darwin user threads have access to the following structure
>> for the GPR registers on Mac OS X:
>> 
>>    struct GPR
>>    {
>>        uint64_t rax;
>>        uint64_t rbx;
>>        uint64_t rcx;
>>        uint64_t rdx;
>>        uint64_t rdi;
>>        uint64_t rsi;
>>        uint64_t rbp;
>>        uint64_t rsp;
>>        uint64_t r8;
>>        uint64_t r9;
>>        uint64_t r10;
>>        uint64_t r11;
>>        uint64_t r12;
>>        uint64_t r13;
>>        uint64_t r14;
>>        uint64_t r15;
>>        uint64_t rip;
>>        uint64_t rflags;
>>        uint64_t cs;
>>        uint64_t fs;
>>        uint64_t gs;
>>    };
>> 
>> Does linux have the exact same registers? If not, I would vote to keep
>> each implementation separate.
> 
> At first glance it looks like ES, DS and SS are available on linux as
> well, but IIRC are always zero on 64 bit arch regardless.
> 
>> Also different OS version of the same system may have more or less
>> registers available. So code could be dynamically determine which
>> registers are available and different registers contexts could be
>> returned as a result.
> 
> OK.  I did not consider this possibility.
> 
>> There is also a rule that all register numbers defined by a context
>> must start at zero and have no gaps, which makes making a single
>> definition for registers for a given architecture even harder because
>> you might have to zero out registers that 
>> 
>> So I would say to keep these separate and allow each plug-in to define
>> regiters contexts that exactly match the current registers that can be
>> provided by each platform.
> 
> Thanks so much for the feedback!  This is very helpful for a newcomer
> such as myself!  As I get the plugin ready for commit I will provide
> private versions of the register context.
> 
> 
> BTW, any hope some of the LLDB devs will show up on #llvm?

That is on my todo list, I will try and get on there ASAP!

I look forward to seeing you land your patch. I will try and take a look at it after my 4PM (PST) meeting.

Greg Clayton