Re: [Dwarf-Discuss] DWARF5 line table file numbering inconsistent

[Eric Christopher via Dwarf-Discuss]

"This margin is too narrow to contain..." ;)

I'd like to see the doc - it's easy to believe we've gotten something wrong
here.. Might be good to fix this as textual edits rather than waiting on a
full dwarf standard release because we're going to run into this a lot if
we can't get it sorted quickly as multiple producers all produce something
slightly different and incompatible.

Thoughts?

-eric

On Thu, Oct 15, 2020 at 11:38 AM David Anderson via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> I think the following (while not news) needs to be said
> simply and directly.
>
> It is impossible to obey all the DWARF5 rules
> on file numbering in the line table
> at the same time. They contradict each other,
> taking the standard as a whole.
> [this consistency issue is solely DWARF5].
>
> A simple solution  is to say that
> the file number value 0 meaning of 'no file'
> is eliminated so that part
> of Section 2.14 page 50 is invalidated.
> So then we have a zero-based file array
> along with all references to it.
> And declare that the 'file' line table
> register defaults to zero (DWARF5 Table 6.4 Page
> 153).  Then the standard is self-consistent.
> (Clang has been using this approach for some time now).
>
> I created a document documenting all the places
> in the standard involving line table file numbering
> but this emaill is already long enough.
>
> David Anderson
>
> --
> Of course power tools and alcohol don't mix.
> Everyone knows power tools aren't soluble in alcohol.
> -- Crazy Nigel
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

[Eric Christopher via Dwarf-Discuss]

On Mon, Mar 30, 2020, 5:37 PM David Blaikie  wrote:

>
>
> On Sun, Mar 29, 2020 at 3:44 PM Cary Coutant  wrote:
>
>> >> > Yep - unless someone has significant objections my plan is currently:
>> >> >
>> >> > Emit a v5 index with extension/non-standard extra column indexes
>> (specifically: DW_SECT_LOC and 9 and DW_SECT_MACINFO at 10). I hope those
>> can at least be reserved (like DW_SECT value 2 (originally DW_SECT_TYPES)
>> was in DWARFv5) in DWARFv6. & maybe open up an extension space in the
>> future.
>> >>
>> >> That sounds good to me. When I saw that number 2 (debug_types in the
>> >> fission extension) was reserved, I originally assumed this was what
>> >> had already happened.
>>
>> The pre-v5 dwp format was just a prototype, accessed via
>> --experimental GCC flags, and I don't think we ever intended to
>> support mixing pre-v5 dwo files with standard v5 dwo files. I'd
>> recommend your original option #1 (invalid/unsupported). Thus, you
>> shouldn't need DW_SECT_LOC or DW_SECT_MACINFO.
>>
>
> That'd be really difficult (I think I'd go so far as to say - it wouldn't
> be done that way) for an environment like Google (or other large projects)
> that want to change the default. It's important not to get into a situation
> where the flag flip from v4 to v5 is overridable, so that we can readily
> opt-out of v5 on a per translation unit basis if there happen to be a
> handful of translation units that trip over uncommon bugs without having to
> rollback the whole codebase each time we hit something like that.
>
> So I'd say at the very least, I think we'll implement a v4+v5 index in our
> internal port of binutils/gold dwp and gdb - and I'd really hope to be able
> to upstream those for anyone else who might be in a similar situation.
>
> I guess it's possible we could opt-out of split DWARF and opt out of v5
> for such translation units (though there's currently no flag to undo
> -gsplit-dwarf on the command line  -ah, there is in GCC (-gno-split-dwarf)
> but not in Clang, so we could add that). Does make things a bit awkward,
> but not impossible, and seems like in the future we're going to have to
> keep backwards compatibility too, so wouldn't be so bad to keep it for v4
> too, would it?
>

Also anyone having to deal with precompiled objects...



>
>>
>> The .debug_types sections were moved back into .debug_info sections at
>> the very last minute, so we just removed DW_SECT_TYPES without
>> renumbering the later values. As best I recall, that was just a nod
>> towards some compatibility with the prototype format, but it wasn't
>> intended to provide for complete compatibility.
>>
>> I don't believe we ever supported .debug_macinfo in the prototype, so
>> I wasn't concerned with the renumbering around DW_SECT_MACRO and
>> DW_SECT_MACINFO.
>>
>> I agree that we should have reserved an extension range for DW_SECT
>> values. It's probably safe to pick some arbitrarily large values if
>> you need to extend this.
>>
>> For DWARF-64 support, I truly hoped that we wouldn't ever need it, but
>> if it was ever necessary, the mechanism I had in mind was to simply
>> replace .debug_cu_index sections with .debug_cu_index_64 sections (and
>> likewise for .debug_tu_index). Maybe DWARF v6 will address this. Keep
>> in mind that the .dwp can be an ELFCLASS64 object file, and its total
>> size can grow larger than 4GB, even if .debug_cu_index can't support
>> any section offsets larger than 4GB.
>>
>> -cary
>>
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] debug_names - what should go in ?

[Eric Christopher via Dwarf-Discuss]

I have nothing to add to what Paul just said :)

This is definitely the intent and what we should do.

-eric

On Tue, Apr 10, 2018 at 10:26 AM Paul Robinson via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> The intent of the index is given pretty plainly in the non-normative text
> at the bottom of p.137; you should be able to look up any unqualified name
> in the index.  If the normative text doesn't accomplish that, we have an
> opportunity to improve the spec. J
>
>
>
> FWIW here's my take:
>
>
>
> Enumerations are a bit unusual in that the enumerators are children of the
> enumeration type, but the enumerator names are not qualified by the type
> name (usually—a C++ enum-class should not put enumerators into the index, I
> think).  But you need some rule that excludes enumerations that are not
> otherwise "global" (e.g., they are contained in a class or local to a
> function).
>
>
>
> For imported entities, I'd say if the imported entity would have satisfied
> the criteria for inclusion in the index if it had been "inlined" at the
> point where it was imported, then it ought to be in the index.
>
> --paulr
>
>
>
>
>
> *From:* Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] *On
> Behalf Of *David Blaikie via Dwarf-Discuss
> *Sent:* Tuesday, April 10, 2018 12:30 PM
> *To:* Pavel Labath
> *Cc:* dwarf-discuss@lists.dwarfstd.org
> *Subject:* Re: [Dwarf-Discuss] debug_names - what should go in ?
>
>
>
> Yep - sounds like it to me.
>
> I suppose, arguably, one could say that successful name lookups of things
> in the index can be fast, while lookups that fail, or find names not in the
> index may be slow - but that seems unacceptable to me (in many cases "slow"
> would be "prohibitively slow" especially the first time - since it'd amount
> to the non-index case: the consumer having to build its own index from
> scratch)
>
> Maybe Adrian or Eric can talk to how the Apple indexes worked in these
> cases.
>
>
>
> On Tue, Apr 10, 2018 at 9:24 AM Pavel Labath  wrote:
>
> On Tue, 10 Apr 2018 at 16:44, David Blaikie  wrote:
>
> I'd say any case where a consumer couldn't actually rely on the table to
> do name resolution would be a bug - or at least something that needs to be
> seriously considered/discussed/figured out how the name table can be used
> in those situations.
>
>
>
> Agreed.
>
>
>
> This question can be demonstrated on a simple c++ program
>
> 
>
> namespace namesp1 { int var; }
>
> namespace namesp2 = namesp1; // DW_TAG_imported_declaration
>
>
>
> enum enum_type { enumerator }; // DW_TAG_enumeration_type,
> DW_TAG_enumerator
>
>
>
> int main() {
>
>   return namesp2::var + enumerator;
>
> }
>
> 
>
>
>
> Debugging with gdb (without any indexes), the following 4 expressions
> succeed
>
> 1) namesp1::var
>
> 2) namesp2::var
>
> 3) (enum_type)0
>
> 4) enumerator
>
>
>
> The question is how should an index-aware debugger find the entities
> referenced by expressions 2 and 4 if they are not present in the index?
>
>
>
> They way I see it -- it can't. Which would be a bug in the spec by your
> definition.
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org