[lldb-dev] Update on Linux work.
gclayton at apple.com
Wed Jul 21 15:57:00 PDT 2010
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
>> 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
>> 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
> 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.
More information about the lldb-dev