[lldb-dev] Update on Linux work.

[Stephen Wilson]

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. 

>> - 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?


Thanks again,
Steve