[ dwarfdump ] Add symbolic dump of known DWARF attribute values.

Frédéric Riss friss at apple.com
Thu Sep 4 06:56:38 PDT 2014


> On 04 Sep 2014, at 14:54, Frédéric Riss <friss at apple.com> wrote:
> 
> I sent out a new version using phabricator. I’m not sure it has reached the list…
> 

I’m pretty sure it didn’t hit the list. Here it is:

http://reviews.llvm.org/D5187

Fred

> Regarding the ones that we don’t emit, I don’t think they matter for us today:
>  - DW_AT_decimal_sign is there to describe non-standard decimal types. I don’t think we have support for that?
>  - DW_AT_endianity permits a per-variable endianness setting. Again, no support for that I think.
>  - DW_AT_identifier_case sets the case-senstivity for the unit. Are there cases where the debugger won’t know how to infer that from the language?
>  - DW_AT_ordering describes multi-dimensional array layout. Maybe this could be useful for Fortran, I’m not sure.
>  - DW_AT_discr_value is there for the native support of Variant types.
>  - DW_AT_calling_convention might be kinda interesting to tag functions that are compiled with a non-standard calling convention. This way the debugger would stay away from those.
> 
> Fred
> 
> 
>> On 03 Sep 2014, at 23:01, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> Such a function might even go in Dwarf.h/Dwarf.cpp
>> 
>> (& do we have any (/should we add some) for these various attributes? The test case updates touch on a few of these attributes, but not all of them)
>> 
>> 
>> On Wed, Sep 3, 2014 at 1:56 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> Perhaps we could avoid the goto & offload some of the repetition from the macro like this:
>> 
>> const char *Name = nullptr;
>> 
>> switch (attr) {
>> #define ENUM_TO_STRING_ATTRIBUTE(NAME)
>>   if (Optional<uint64_t> Val = formValue.getAsUnsignedConstant())
>>     Name = NAME##String(*Val);
>>   break;
>> 
>>   case ...
>>     ...
>>   // no default here
>> }
>> 
>> if (Name)
>>   OS << Name;
>> else
>>   formValue.dump(OS, u);
>> 
>> Or even refactor the switch into a function, then you can just have this in the macro:
>> 
>>   if (Optional<uint64_t> Val = ...)
>>     return *Val;
>> 
>> and a "return nullptr" at the end.
>> 
>> 
>> On Wed, Sep 3, 2014 at 1:38 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
>> Here is a new version rebased on the reviewed FormValue accessor patch.
>> 
>> OK?
>> 
>> 
>>> On 03 Sep 2014, at 21:12, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
>>> 
>>>> 
>>>> On Sep 3, 2014, at 12:03 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On 03 Sep 2014, at 20:57, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Sep 3, 2014, at 11:52 AM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
>>>>>> 
>>>>>> This patch introduces symbolic dump of all the DWARF standard values (defined in Dwarf.h). It requires the previous DWARFFormValue accessor patch. The fixed accessibility test shows that it’s much easier to check that the test is actually correct, rather than having to cross-check with the enumerator value.
>>>>>> 
>>>>>> OK?
>>>>>> <dwarfdump-SymbolicAttributes.diff>
>>>>> 
>>>>> If you look at lib/Support/Dwarf.cpp, there is already a similar switch table for converting all the attribute names. We should probably only have one such implementation.
>>>> 
>>>> Really, which one? I see tables converting from various enum to const char * value, but my switch associates DW_AT_* attributes with the corresponding attribute enumeration. This patch uses all the switch functions in Dwarf.cpp, but AFAICS it doesn’t duplicate anything. But maybe I’m looking at the wrong place?
>>> 
>>> My apologies, you are correct! That email went out too fast.
>>> 
>>> -- adrian
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140904/2505a036/attachment.html>


More information about the llvm-commits mailing list