[Lldb-commits] [PATCH] Introduce DWARFDataExtractor for 64-Bit DWARF parsing

[Greg Clayton]

On Oct 23, 2013, at 5:56 PM, Ed Maste <emaste at freebsd.org> wrote:

> On 23 October 2013 20:12, Greg Clayton <gclayton at apple.com> wrote:
>> Do we need two functions, one for length and one for DIE offset? Can we consolidate this down to 1 function with a name like "GetDWARFWord" or something better? GetDWARFOffset? We could then switch m_is_dwarf64 to a LazyBool which is set to eLazyBoolCalculate to start with, and set it to eLazyBoolYes or eLazyBoolNo and then do the right thing from there on out.
>> 
>> With the current code, you would have to call GetDWARFInitialLength() first prior to calling and GetDWARFOffset() functions. This might be ok if every DWARF section that contains these special 64 bit entries always has a length that starts it off, but I am guessing that some sections might not have a length?
> 
> The sections that support 64-bit DWARF all have an initial length that
> is either 32 or 96 bits (0xffffffff followed by the 64-bit diff for
> the latter).  The subsequent offsets and lengths are then 32- or
> 64-bit.
> 
> I suppose using the same logic for all cases would actually work, but
> this isn't allowed according to the spec.  It also specifies that a
> single CU must be all 32- or all 64-bit.

Ok, sounds good. Now DWARF 64 doesn't scare me as much as it used to. I had never really paid attention to the spec, but if it is just the initial length that is 12 bytes, then your current diffs make perfect sense.

Greg