[lldb-dev] Update on Linux work.

[Greg Clayton]

On Jul 21, 2010, at 11:39 AM, Stephen Wilson wrote:

> 
> Hi all!
> 
> This is a quick update on some work I have been doing on the linux
> front, specifically a Process plugin for that platform.  
> 
> The current effort is still at an early stage.  In short, we can launch
> an inferior process and set/step-over breakpoints.

That is great news!

> However, I am thinking about merging this initial work into the tree
> sooner rather than later to avoid dumping a huge patch on everyone at a
> later time.  Although *not quite ready*, you can see the current plugin
> code here:
> 
> http://github.com/ice799/lldb/tree/swilson-process/source/Plugins/Process/Linux
> 
> 
> A few issues I came across while working on this which should be
> resolved before the linux plugin can be merged:
> 
> - 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.


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

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.

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 don't exist.

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.

> 
> Take care,
> Steve
> 
> 
> <RegisterContext_x86_64.h><RegisterContext_x86_64.cpp>_______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev