llvm dev - Apr 2017 - recognise DW_AT_SUN_amd64_parmdump dwarf attribute

> On Apr 27, 2017, at 8:38 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> This'll need a test case, in any case.
In case you're wondering, one way to do this would be to add an assembler
source file, compile it and run it through llvm-dwarfdump.
Alternatively you can use the new yaml2obj tool that is being developed.

-- adrian
> 
> Adrian/Paul: Pondering this, any thoughts on how conflicts in the vendor
extension range of attributes, forms, etc, should be resolved if they ever come
up? (each vendor is free to define them as they wish, so it could be that
multiple vendors have different definitions of the same code/number & would
be ambiguous) I don't see any reason to block this patch if it doesn't
have such a conflict, since there are already other vendor extension codes
supported here for a variety of vendors - but does make me wonder.
> 
> On Thu, Apr 27, 2017 at 2:50 AM David Gwynne via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> sun created this tag for identifying functions that dumped their
> register arguments onto the stack.
> 
> this is enough for llvm-dwarfdump to recognise and print the attribute.
> 
> hopefully someone will commit it.
> 
> cheers,
> dlg
> 
> Index: include/llvm/Support/Dwarf.def
> ==================================================================> ---
include/llvm/Support/Dwarf.def      (revision 301500)
> +++ include/llvm/Support/Dwarf.def      (working copy)
> @@ -343,6 +343,8 @@
>  HANDLE_DW_AT(0x2134, GNU_pubnames, 0, GNU)
>  HANDLE_DW_AT(0x2135, GNU_pubtypes, 0, GNU)
>  HANDLE_DW_AT(0x2136, GNU_discriminator, 0, GNU)
> +// Sun Extension
> +HANDLE_DW_AT(0x2224, SUN_amd64_parmdump, 0, GNU)
>  // Borland extensions.
>  HANDLE_DW_AT(0x3b11, BORLAND_property_read, 0, BORLAND)
>  HANDLE_DW_AT(0x3b12, BORLAND_property_write, 0, BORLAND)
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170427/63cf4a27/attachment.html>

The patch should probably define a new vendor code for SUN rather than re-use
GNU.  And it needs a test.

We've been fortunate (or maybe it's a testament to the care exercised by
people who define extensions) to see no conflicts in vendor extensions.  If/when
it ever comes up we'll have to do something, I think Adrian had a pretty
reasonable idea.
--paulr

From: aprantl at apple.com [mailto:aprantl at apple.com]
Sent: Thursday, April 27, 2017 8:50 AM
To: David Blaikie
Cc: David Gwynne; llvm-dev at lists.llvm.org; Robinson, Paul
Subject: Re: [llvm-dev] recognise DW_AT_SUN_amd64_parmdump dwarf attribute


On Apr 27, 2017, at 8:38 AM, David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>> wrote:

This'll need a test case, in any case.

In case you're wondering, one way to do this would be to add an assembler
source file, compile it and run it through llvm-dwarfdump.
Alternatively you can use the new yaml2obj tool that is being developed.

-- adrian



Adrian/Paul: Pondering this, any thoughts on how conflicts in the vendor
extension range of attributes, forms, etc, should be resolved if they ever come
up? (each vendor is free to define them as they wish, so it could be that
multiple vendors have different definitions of the same code/number & would
be ambiguous) I don't see any reason to block this patch if it doesn't
have such a conflict, since there are already other vendor extension codes
supported here for a variety of vendors - but does make me wonder.
On Thu, Apr 27, 2017 at 2:50 AM David Gwynne via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
sun created this tag for identifying functions that dumped their
register arguments onto the stack.

this is enough for llvm-dwarfdump to recognise and print the attribute.

hopefully someone will commit it.

cheers,
dlg

Index: include/llvm/Support/Dwarf.def
==================================================================---
include/llvm/Support/Dwarf.def      (revision 301500)
+++ include/llvm/Support/Dwarf.def      (working copy)
@@ -343,6 +343,8 @@
 HANDLE_DW_AT(0x2134, GNU_pubnames, 0, GNU)
 HANDLE_DW_AT(0x2135, GNU_pubtypes, 0, GNU)
 HANDLE_DW_AT(0x2136, GNU_discriminator, 0, GNU)
+// Sun Extension
+HANDLE_DW_AT(0x2224, SUN_amd64_parmdump, 0, GNU)
 // Borland extensions.
 HANDLE_DW_AT(0x3b11, BORLAND_property_read, 0, BORLAND)
 HANDLE_DW_AT(0x3b12, BORLAND_property_write, 0, BORLAND)
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170427/a744d464/attachment.html>

> On 28 Apr 2017, at 01:49, Adrian Prantl <aprantl at apple.com> wrote:
> 
> 
>> On Apr 27, 2017, at 8:38 AM, David Blaikie <dblaikie at
gmail.com> wrote:
>> 
>> This'll need a test case, in any case.
> 
> In case you're wondering, one way to do this would be to add an
assembler source file, compile it and run it through llvm-dwarfdump.
cool, can you point me at an existing one that i can use as a reference?
> Alternatively you can use the new yaml2obj tool that is being developed.
ill try the first suggestion for now.

cheers,
dlg
> 
> -- adrian
> 
>> 
>> Adrian/Paul: Pondering this, any thoughts on how conflicts in the
vendor extension range of attributes, forms, etc, should be resolved if they
ever come up? (each vendor is free to define them as they wish, so it could be
that multiple vendors have different definitions of the same code/number &
would be ambiguous) I don't see any reason to block this patch if it
doesn't have such a conflict, since there are already other vendor extension
codes supported here for a variety of vendors - but does make me wonder.
>> 
>> On Thu, Apr 27, 2017 at 2:50 AM David Gwynne via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>> sun created this tag for identifying functions that dumped their
>> register arguments onto the stack.
>> 
>> this is enough for llvm-dwarfdump to recognise and print the attribute.
>> 
>> hopefully someone will commit it.
>> 
>> cheers,
>> dlg
>> 
>> Index: include/llvm/Support/Dwarf.def
>>
==================================================================>> ---
include/llvm/Support/Dwarf.def      (revision 301500)
>> +++ include/llvm/Support/Dwarf.def      (working copy)
>> @@ -343,6 +343,8 @@
>>  HANDLE_DW_AT(0x2134, GNU_pubnames, 0, GNU)
>>  HANDLE_DW_AT(0x2135, GNU_pubtypes, 0, GNU)
>>  HANDLE_DW_AT(0x2136, GNU_discriminator, 0, GNU)
>> +// Sun Extension
>> +HANDLE_DW_AT(0x2224, SUN_amd64_parmdump, 0, GNU)
>>  // Borland extensions.
>>  HANDLE_DW_AT(0x3b11, BORLAND_property_read, 0, BORLAND)
>>  HANDLE_DW_AT(0x3b12, BORLAND_property_write, 0, BORLAND)
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

> On Apr 27, 2017, at 5:42 PM, David Gwynne <david at gwynne.id.au>
wrote:
> 
> 
>> On 28 Apr 2017, at 01:49, Adrian Prantl <aprantl at apple.com>
wrote:
>> 
>> 
>>> On Apr 27, 2017, at 8:38 AM, David Blaikie <dblaikie at
gmail.com> wrote:
>>> 
>>> This'll need a test case, in any case.
>> 
>> In case you're wondering, one way to do this would be to add an
assembler source file, compile it and run it through llvm-dwarfdump.
> 
> cool, can you point me at an existing one that i can use as a reference?
Here's a very recent example:

https://reviews.llvm.org/D32618
> 
>> Alternatively you can use the new yaml2obj tool that is being
developed.
> 
> ill try the first suggestion for now.
> 
> cheers,
> dlg
> 
>> 
>> -- adrian
>> 
>>> 
>>> Adrian/Paul: Pondering this, any thoughts on how conflicts in the
vendor extension range of attributes, forms, etc, should be resolved if they
ever come up? (each vendor is free to define them as they wish, so it could be
that multiple vendors have different definitions of the same code/number &
would be ambiguous) I don't see any reason to block this patch if it
doesn't have such a conflict, since there are already other vendor extension
codes supported here for a variety of vendors - but does make me wonder.
>>> 
>>> On Thu, Apr 27, 2017 at 2:50 AM David Gwynne via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>> sun created this tag for identifying functions that dumped their
>>> register arguments onto the stack.
>>> 
>>> this is enough for llvm-dwarfdump to recognise and print the
attribute.
>>> 
>>> hopefully someone will commit it.
>>> 
>>> cheers,
>>> dlg
>>> 
>>> Index: include/llvm/Support/Dwarf.def
>>>
==================================================================>>>
--- include/llvm/Support/Dwarf.def      (revision 301500)
>>> +++ include/llvm/Support/Dwarf.def      (working copy)
>>> @@ -343,6 +343,8 @@
>>> HANDLE_DW_AT(0x2134, GNU_pubnames, 0, GNU)
>>> HANDLE_DW_AT(0x2135, GNU_pubtypes, 0, GNU)
>>> HANDLE_DW_AT(0x2136, GNU_discriminator, 0, GNU)
>>> +// Sun Extension
>>> +HANDLE_DW_AT(0x2224, SUN_amd64_parmdump, 0, GNU)
>>> // Borland extensions.
>>> HANDLE_DW_AT(0x3b11, BORLAND_property_read, 0, BORLAND)
>>> HANDLE_DW_AT(0x3b12, BORLAND_property_write, 0, BORLAND)
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>