From louzonr@yahoo.com  Tue Oct  4 18:03:15 2011
From: louzonr@yahoo.com (Ron Louzon)
Date: Tue, 4 Oct 2011 11:03:15 -0700 (PDT)
Subject: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
Message-ID: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>

I am working with DWARF output from the GNU 4.4 C++ compiler and I have a question about the output for structure member locations.? I am looking at the following?information for a class and its members?
?
?<1><2819e>: Abbrev Number: 108 (DW_TAG_class_type)
??? <2819f>?? DW_AT_name??????? : (indirect string, offset: 0x26a2d): CmpCommandListHandler?
??? <281a3>?? DW_AT_byte_size?? : 20560?
??? <281a5>?? DW_AT_decl_file?? : 55?
??? <281a6>?? DW_AT_decl_line?? : 31?
??? <281a7>?? DW_AT_sibling???? : <0x2834c>?

?<2><281ab>: Abbrev Number: 98 (DW_TAG_member)
??? <281ac>?? DW_AT_name??????? : (indirect string, offset: 0xb70e): activeWcl?
??? <281b0>?? DW_AT_decl_file?? : 55?
??? <281b1>?? DW_AT_decl_line?? : 75?
??? <281b2>?? DW_AT_type??????? : <0x27bc2>?
??? <281b6>?? DW_AT_data_member_location: 0?
??? <281b7>?? DW_AT_accessibility: 3?(private)

?<2><281b8>: Abbrev Number: 98 (DW_TAG_member)
??? <281b9>?? DW_AT_name??????? : (indirect string, offset: 0x1ca9d): activeMcl?
??? <281bd>?? DW_AT_decl_file?? : 55?
??? <281be>?? DW_AT_decl_line?? : 78?
??? <281bf>?? DW_AT_type??????? : <0x277ee>?
??? <281c3>?? DW_AT_data_member_location: 8216?
??? <281c6>?? DW_AT_accessibility: 3?(private)
?
In the past, when dealing with structure and class members, I have always been able to use the dwarf_loclist() and dwarf_loclist_n() functions to retrieve location information for the members.? These functions would return the offset which was applicable for whatever member was being examined.? With the GNU 4.4 compiler, these functions are returning an error because the DW_AT_data_member_location attribute is of the form DW_FORM_sdata and these functions do not handle that attribute form.??
?
I have never encountered this before.? I can deal with this by reading the data as a signed number but is this normal?? Do I always need to examine the form type to determine how to deal with a DW_AT_data_member_location attribute or is this a special case due to abnormal output from the GNU 4.4 compiler?
?
Thanks.
Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111004/0722619e/attachment.htm>


From ron.brender@gmail.com  Tue Oct  4 18:56:16 2011
From: ron.brender@gmail.com (Ron Brender)
Date: Tue, 04 Oct 2011 14:56:16 -0400
Subject: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
In-Reply-To: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>
References: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>
Message-ID: <4E8B56D0.6090203@gmail.com>

The option to use DW_FORM_sdata in the DW_AT_location attribute of a 
field is new in DWARF *V4*. It is a size optimization for the very 
common case where the field offset is a constant. (Otherwise, an address 
expression is required which is at least a couple bytes larger.) I would 
expect that dwarf_loclist() and dwarf_loclist_n() already must use the 
form in order to distinguish a simple expression versus a location 
list--handling the sdata case should be a minor extension.

Ron

----------------------------------------------------
On 10/4/2011 2:03 PM, Ron Louzon wrote:
> I am working with DWARF output from the GNU 4.4 C++ compiler and I 
> have a question about the output for structure member locations.  I am 
> looking at the following information for a class and its members
> <1><2819e>: Abbrev Number: 108 (DW_TAG_class_type)
> <2819f>   DW_AT_name        : (indirect string, offset: 0x26a2d): 
> CmpCommandListHandler
> <281a3>   DW_AT_byte_size   : 20560
> <281a5>   DW_AT_decl_file   : 55
> <281a6>   DW_AT_decl_line   : 31
> <281a7>   DW_AT_sibling     : <0x2834c>
> <2><281ab>: Abbrev Number: 98 (DW_TAG_member)
> <281ac>   DW_AT_name        : (indirect string, offset: 0xb70e): 
> activeWcl
> <281b0>   DW_AT_decl_file   : 55
> <281b1>   DW_AT_decl_line   : 75
> <281b2>   DW_AT_type        : <0x27bc2>
> <281b6>   DW_AT_data_member_location: 0
> <281b7>   DW_AT_accessibility: 3 (private)
> <2><281b8>: Abbrev Number: 98 (DW_TAG_member)
> <281b9>   DW_AT_name        : (indirect string, offset: 0x1ca9d): 
> activeMcl
> <281bd>   DW_AT_decl_file   : 55
> <281be>   DW_AT_decl_line   : 78
> <281bf>   DW_AT_type        : <0x277ee>
> <281c3>   DW_AT_data_member_location: 8216
> <281c6>   DW_AT_accessibility: 3 (private)
> In the past, when dealing with structure and class members, I have 
> always been able to use the dwarf_loclist() and dwarf_loclist_n() 
> functions to retrieve location information for the members.  These 
> functions would return the offset which was applicable for whatever 
> member was being examined.  With the GNU 4.4 compiler, these functions 
> are returning an error because the DW_AT_data_member_location 
> attribute is of the form DW_FORM_sdata and these functions do not 
> handle that attribute form.
> I have never encountered this before.  I can deal with this by reading 
> the data as a signed number but is this normal?  Do I always need to 
> examine the form type to determine how to deal with a 
> DW_AT_data_member_location attribute or is this a special case due to 
> abnormal output from the GNU 4.4 compiler?
> Thanks.
> Ron
>
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111004/b545867e/attachment.htm>


From davea42@earthlink.net  Tue Oct  4 19:08:01 2011
From: davea42@earthlink.net (David Anderson)
Date: Tue, 04 Oct 2011 12:08:01 -0700
Subject: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
In-Reply-To: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>
References: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>
Message-ID: <4E8B5991.3050006@earthlink.net>

On 10/04/2011 11:03 AM, Ron Louzon wrote:
>
> In the past, when dealing with structure and class members, I have 
> always been able to use the dwarf_loclist() and dwarf_loclist_n() 
> functions to retrieve location information for the members.  These 
> functions would return the offset which was applicable for whatever 
> member was being examined.  With the GNU 4.4 compiler, these functions 
> are returning an error because the DW_AT_data_member_location 
> attribute is of the form DW_FORM_sdata and these functions do not 
> handle that attribute form.
> I have never encountered this before.  I can deal with this by reading 
> the data as a signed number but is this normal?  Do I always need to 
> examine the form type to determine how to deal with a 
> DW_AT_data_member_location attribute or is this a special case due to 
> abnormal output from the GNU 4.4 compiler?
>

I added support  (June 2011 I think) to dwarfdump
for an arbitrary constant as the value of DW_AT_data_member_location
and I seem to recall this was exactly because of gcc and DW_FORM_sdata on
DW_AT_data_member_location.    The signed constant kind of surprised me too.

David Anderson.

-- 
I have a rock garden. Last week three of them died. -- Richard Diran




From jakub@redhat.com  Tue Oct  4 19:17:31 2011
From: jakub@redhat.com (Jakub Jelinek)
Date: Tue, 4 Oct 2011 21:17:31 +0200
Subject: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
In-Reply-To: <4E8B56D0.6090203@gmail.com>
References: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>
	<4E8B56D0.6090203@gmail.com>
Message-ID: <20111004191731.GQ19412@tyan-ft48-01.lab.bos.redhat.com>

On Tue, Oct 04, 2011 at 02:56:16PM -0400, Ron Brender wrote:
> The option to use DW_FORM_sdata in the DW_AT_location attribute of a
> field is new in DWARF *V4*. It is a size optimization for the very
> common case where the field offset is a constant. (Otherwise, an
> address expression is required which is at least a couple bytes
> larger.) I would expect that dwarf_loclist() and dwarf_loclist_n()
> already must use the form in order to distinguish a simple
> expression versus a location list--handling the sdata case should be
> a minor extension.

It is already in DWARF *V3* actually.  Just in *V3* DW_FORM_data{4,8}
on DW_AT_data_member_location has to be considered as loclistptr,
while in *V4* it is constant offset too.

	Jakub



From louzonr@yahoo.com  Tue Oct  4 19:34:18 2011
From: louzonr@yahoo.com (Ron Louzon)
Date: Tue, 4 Oct 2011 12:34:18 -0700 (PDT)
Subject: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
In-Reply-To: <4E8B5991.3050006@earthlink.net>
References: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>
	<4E8B5991.3050006@earthlink.net>
Message-ID: <1317756858.52367.YahooMailNeo@web114720.mail.gq1.yahoo.com>

Since dwarf_loclist_n()?already supports DW_FORM_data4 and?DW_FORM_data8, is there any plan to update it in a future release to accomodate?DW_FORM_sdata?
?
Thanks for the help with this.
- Ron

From: David Anderson <davea42@earthlink.net>
To: dwarf-discuss at lists.dwarfstd.org
Sent: Tuesday, October 4, 2011 3:08 PM
Subject: Re: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?

On 10/04/2011 11:03 AM, Ron Louzon wrote:
> 
> In the past, when dealing with structure and class members, I have always been able to use the dwarf_loclist() and dwarf_loclist_n() functions to retrieve location information for the members.? These functions would return the offset which was applicable for whatever member was being examined.? With the GNU 4.4 compiler, these functions are returning an error because the DW_AT_data_member_location attribute is of the form DW_FORM_sdata and these functions do not handle that attribute form.
> I have never encountered this before.? I can deal with this by reading the data as a signed number but is this normal?? Do I always need to examine the form type to determine how to deal with a DW_AT_data_member_location attribute or is this a special case due to abnormal output from the GNU 4.4 compiler?
> 

I added support? (June 2011 I think) to dwarfdump
for an arbitrary constant as the value of DW_AT_data_member_location
and I seem to recall this was exactly because of gcc and DW_FORM_sdata on
DW_AT_data_member_location.? ? The signed constant kind of surprised me too.

David Anderson.

-- I have a rock garden. Last week three of them died. -- Richard Diran

_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss at lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111004/de9b2e9a/attachment.htm>


From davea42@earthlink.net  Thu Oct  6 00:12:36 2011
From: davea42@earthlink.net (David Anderson)
Date: Wed, 05 Oct 2011 17:12:36 -0700
Subject: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
In-Reply-To: <1317756858.52367.YahooMailNeo@web114720.mail.gq1.yahoo.com>
References: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>	<4E8B5991.3050006@earthlink.net>
	<1317756858.52367.YahooMailNeo@web114720.mail.gq1.yahoo.com>
Message-ID: <4E8CF274.8090204@earthlink.net>

On 10/04/2011 12:34 PM, Ron Louzon wrote:
> Since dwarf_loclist_n() already supports DW_FORM_data4 
> and DW_FORM_data8, i s there any plan to update it in a future release 
> to accomodate DW_FORM_sdata?
>
For the record, a solution to proper handling of 
DW_AT_data_member_location  (while being
sensitive to the dwarf version of the compilation unit under 
consideration)  when using libdwarf
is the one used in dwarfdump:

             fc = dwarf_get_form_class(version,attr,offset_size,theform);
             if(fc == DW_FORM_CLASS_CONSTANT) {
                    ...and here read the data as a constant.
             } else {
                    call dwarf_loclist_n
              }

dwarf_get_form_class () understands that DW_FORM_data4 (for example) is 
a constant for DWARF4
but is a loclist offset for 32bit DWARF3.  And so on.

Anyone with information that I've messed up here, please let me know...

A new release is in the works, I've found a few small bugs and now 
dwarfdump2
will have all the checking and option features of dwarfdump.

Many thanks to Carlos Alberto Enciso and Paul Marinescu for 
recent-assistance/test-cases!
My apologies to folks who have helped but are not mentioned here.
DavidA.



From louzonr@yahoo.com  Thu Oct  6 12:04:43 2011
From: louzonr@yahoo.com (Ron Louzon)
Date: Thu, 6 Oct 2011 05:04:43 -0700 (PDT)
Subject: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
In-Reply-To: <4E8CC645.1070206@earthlink.net>
References: <1317751395.27769.YahooMailNeo@web114714.mail.gq1.yahoo.com>
	<4E8B5991.3050006@earthlink.net>
	<1317756858.52367.YahooMailNeo@web114720.mail.gq1.yahoo.com>
	<4E8CC645.1070206@earthlink.net>
Message-ID: <1317902683.7109.YahooMailNeo@web114717.mail.gq1.yahoo.com>

Dave,
?
I didn't know about the dwarf_get_form_class() function.? I was looking at the attribute's form type which essentially gives me the same information but dwarf_get_form_class() will make the job cleaner.? 
?
I need to maintain a location description list for variables. As I drill down through pointers to objects and then to the object members which may themselves be pointers to objects, I am required to build a location description list which describes the address of a member.? Once the pointer values are?retrieved, I then fill in the holes in the location description list and generate a physical address.? This means that I must convert the constant member offset into a location description which I add to my list.? It would have been easier for me if, when it encountered a constant, ?the dwarf_loclist_n() function returned a location description which was essentially an add operand and the constant value.
?
Again, thanks for explaining the DWARF 4 changes.
?
- Ron

From: David Anderson <davea42@earthlink.net>
To: Ron Louzon <louzonr at yahoo.com>
Sent: Wednesday, October 5, 2011 5:04 PM
Subject: Re: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?

On 10/04/2011 12:34 PM, Ron Louzon wrote:
> Since dwarf_loclist_n() already supports DW_FORM_data4 and DW_FORM_data8, i s there any plan to update it in a future release to accomodate DW_FORM_sdata?
> Thanks for the help with this.
> - Ron
> 
> *From:* David Anderson <davea42 at earthlink.net>
> *To:* dwarf-discuss at lists.dwarfstd.org
> *Sent:* Tuesday, October 4, 2011 3:08 PM
> *Subject:* Re: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
> 
> On 10/04/2011 11:03 AM, Ron Louzon wrote:
> >
> > In the past, when dealing with structure and class members, I have always been able to use the dwarf_loclist() and dwarf_loclist_n() functions to retrieve location information for the members.? These functions would return the offset which was applicable for whatever member was being examined.? With the GNU 4.4 compiler, these functions are returning an error because the DW_AT_data_member_location attribute is of the form DW_FORM_sdata and these functions do not handle that attribute form.
> > I have never encountered this before.? I can deal with this by reading the data as a signed number but is this normal?? Do I always need to examine the form type to determine how to deal with a DW_AT_data_member_location attribute or is this a special case due to abnormal output from the GNU 4.4 compiler?
> >
> 
> I added support? (June 2011 I think) to dwarfdump
> for an arbitrary constant as the value of DW_AT_data_member_location
> and I seem to recall this was exactly because of gcc and DW_FORM_sdata on
> DW_AT_data_member_location.? ? The signed constant kind of surprised me too.

Ron, I have a real test case with the issue you bring up, on with DW_AT_data_member_location
being? DW_FORM_sdata..
The decision of whether to call dwarf_loclist_n(),
or to just accept a constant for DW_AT_data_member_location,
is a choice that is made outside of dwarf_loclist_n().

dwarf_loclist_n() is for location lists, but a DWARF4 constant for DW_AT_data_member_location
means 'do not call dwarf_loclist_n() as there is no loclist here'.? If you take a look at
dwarfdump,
? ? ? ? ? ? fc = dwarf_get_form_class(version,attr,offset_size,theform);
? ? ? ? ? ? if(fc == DW_FORM_CLASS_CONSTANT) {

is how dwarfdump deals with this sort of thing.

Maybe I am misunderstanding your point here.
Do you have a testcase executable or object you can send me (to include in the
libdwarf/dwarfdump tests)? One that gives you trouble?

DavidA.

-- I have a rock garden. Last week three of them died. -- Richard Diran



dwarf-discuss at lists.dwarfstd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111006/5767d4c3/attachment.htm>


From tromey@redhat.com  Thu Oct 20 17:23:27 2011
From: tromey@redhat.com (Tom Tromey)
Date: Thu, 20 Oct 2011 11:23:27 -0600
Subject: [Dwarf-Discuss] RFC: DWARF Extensions for Separate Debug Info
	Files ("Fission")
In-Reply-To: <CAHACq4o43uGDEEKQRiYgnWWXSnDzRD1Z_-4z2HQ=bSaTpgyrjQ@mail.gmail.com>
	(Cary Coutant's message of "Thu, 22 Sep 2011 17:21:44 -0700")
References: <CAHACq4o43uGDEEKQRiYgnWWXSnDzRD1Z_-4z2HQ=bSaTpgyrjQ@mail.gmail.com>
Message-ID: <m3mxcvo9v4.fsf@fleche.redhat.com>

>>>>> "Cary" == Cary Coutant <ccoutant at google.com> writes:

Cary> At Google, we've found that the cost of linking applications with
Cary> debug info is much too high.
[...]

Cary> * .debug_macinfo - Macro information, unaffected by this design.

There is also the new .debug_macro section.  This section refers to
.debug_str, so it will need some updates for your changes there.

Tom



From Richard.Relph@amd.com  Thu Oct 20 17:24:24 2011
From: Richard.Relph@amd.com (Relph, Richard)
Date: Thu, 20 Oct 2011 12:24:24 -0500
Subject: [Dwarf-Discuss] Any real products that do...
Message-ID: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>

Howdy,
    I'm getting push back from my compiler team on the need for accurate column information in the DWARF. We've proceeded pretty far afield from the original problem, but an interesting question has arisen.
    Are there any existing DWARF-based tool chains (compiler and debugger) that use column information to do, say, highlight the fragments of a for statement as execution advances? Or are there other interesting uses of accurate column information out there in debuggers? In particular, multiple column entries in the same file/line...
Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111020/19c39472/attachment.htm>


From John.DelSignore@roguewave.com  Thu Oct 20 17:32:22 2011
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Thu, 20 Oct 2011 13:32:22 -0400
Subject: [Dwarf-Discuss] Any real products that do...
In-Reply-To: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
Message-ID: <4EA05B26.6010301@roguewave.com>

FWIW, TotalView, doesn't use the column information, and in my experience, most of the compilers we support don't bother emitting accurate column information.

Cheers, John D.


Relph, Richard wrote:
> Howdy,
> 
>     I?m getting push back from my compiler team on the need for accurate
> column information in the DWARF. We?ve proceeded pretty far afield from
> the original problem, but an interesting question has arisen.
> 
>     Are there any existing DWARF-based tool chains (compiler and
> debugger) that use column information to do, say, highlight the
> fragments of a for statement as execution advances? Or are there other
> interesting uses of accurate column information out there in debuggers?
> In particular, multiple column entries in the same file/line?
> 
> Thanks,
> 
> Richard
> 



From guitton@adacore.com  Fri Oct 21 09:25:57 2011
From: guitton@adacore.com (Jerome Guitton)
Date: Fri, 21 Oct 2011 11:25:57 +0200
Subject: [Dwarf-Discuss] Any real products that do...
In-Reply-To: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
Message-ID: <20111021092557.GA27275@adacore.com>

Relph, Richard (Richard.Relph at amd.com):

> Are there any existing DWARF-based tool chains (compiler and
> debugger) that use column information to do, say, highlight the
> fragments of a for statement as execution advances? Or are there other
> interesting uses of accurate column information out there in
> debuggers? In particular, multiple column entries in the same
> file/line...

In debuggers, I don't know; I know of such a use in a coverage tool
though.  GNATCoverage uses the column information to compute source
coverage (e.g. MCDC) from execution traces at object level.

Best regards,
Jerome



From David.Earlam@csr.com  Fri Oct 21 15:26:15 2011
From: David.Earlam@csr.com (David Earlam)
Date: Fri, 21 Oct 2011 15:26:15 +0000
Subject: [Dwarf-Discuss] Any real products that do...
In-Reply-To: <4EA05B26.6010301@roguewave.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
	<4EA05B26.6010301@roguewave.com>
Message-ID: <FC0D83C633273A488E45F10E6CBCB46130EBE0B3@CAMEUREXM01.EUROPE.ROOT.PRI>

> >     Are there any existing DWARF-based tool chains (compiler and
> > debugger) that use column information to do, say, highlight the
> > fragments of a for statement as execution advances?

xRay, ASPEX and RealView Debugger would draw a box around column delimited statements in a single line and ARM's RealView Compilation Tools 3 and 4
compilers produce column information to let it do so.

The bottom line of that box covered any descenders (like g or _) in the source view, which was annoying. However, not only did you see the increment separately from the tests in one-line 'for', I seem to recall you could know exactly which of several clauses made a complex 'while' loop -with multiple short circuiting tests- terminate, because as you stepped the box surrounded each observable test 'sequence point'. I can't recall if ARM ever sorted out multi-statement line breakpoints before moving to Eclipse. 

David 


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog



From eager@eagercon.com  Fri Oct 21 16:32:14 2011
From: eager@eagercon.com (Michael Eager)
Date: Fri, 21 Oct 2011 09:32:14 -0700
Subject: [Dwarf-Discuss] Bounced email
Message-ID: <4EA19E8E.9050002@eagercon.com>

Hi --

I'm seeing multiple bounces for several people with address
@linux.ibm.com starting yesterday.  If there is someone at IBM
who could help me contact the intended recipients, please contact me.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



From tromey@redhat.com  Fri Oct 21 17:30:48 2011
From: tromey@redhat.com (Tom Tromey)
Date: Fri, 21 Oct 2011 11:30:48 -0600
Subject: [Dwarf-Discuss] Any real products that do...
In-Reply-To: <FC0D83C633273A488E45F10E6CBCB46130EBE0B3@CAMEUREXM01.EUROPE.ROOT.PRI>
	(David Earlam's message of "Fri, 21 Oct 2011 15:26:15 +0000")
References: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
	<4EA05B26.6010301@roguewave.com>
	<FC0D83C633273A488E45F10E6CBCB46130EBE0B3@CAMEUREXM01.EUROPE.ROOT.PRI>
Message-ID: <m3hb32i75j.fsf@fleche.redhat.com>

>>>>> "David" == David Earlam <David.Earlam at csr.com> writes:

>> >     Are there any existing DWARF-based tool chains (compiler and
>> > debugger) that use column information to do, say, highlight the
>> > fragments of a for statement as execution advances?

David> xRay, ASPEX and RealView Debugger would draw a box around column
David> delimited statements in a single line and ARM's RealView Compilation
David> Tools 3 and 4
David> compilers produce column information to let it do so.

I'm curious if you, or anybody, knows the space penalty for including
the column information in the debuginfo.  GCC could emit it pretty
easily, but I know people worry about size.

Tom



From eager@eagercon.com  Fri Oct 21 17:38:44 2011
From: eager@eagercon.com (Michael Eager)
Date: Fri, 21 Oct 2011 10:38:44 -0700
Subject: [Dwarf-Discuss] Any real products that do...
In-Reply-To: <m3hb32i75j.fsf@fleche.redhat.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
	<4EA05B26.6010301@roguewave.com>
	<FC0D83C633273A488E45F10E6CBCB46130EBE0B3@CAMEUREXM01.EUROPE.ROOT.PRI>
	<m3hb32i75j.fsf@fleche.redhat.com>
Message-ID: <4EA1AE24.5000308@eagercon.com>

On 10/21/2011 10:30 AM, Tom Tromey wrote:
>>>>>> "David" == David Earlam<David.Earlam at csr.com>  writes:
>
>>>>      Are there any existing DWARF-based tool chains (compiler and
>>>> debugger) that use column information to do, say, highlight the
>>>> fragments of a for statement as execution advances?
>
> David>  xRay, ASPEX and RealView Debugger would draw a box around column
> David>  delimited statements in a single line and ARM's RealView Compilation
> David>  Tools 3 and 4
> David>  compilers produce column information to let it do so.
>
> I'm curious if you, or anybody, knows the space penalty for including
> the column information in the debuginfo.  GCC could emit it pretty
> easily, but I know people worry about size.

I think it would be one or two bytes for each TAG which has source coordinates.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



From chris.quenelle@oracle.com  Mon Oct 24 00:35:13 2011
From: chris.quenelle@oracle.com (Chris Quenelle)
Date: Sun, 23 Oct 2011 17:35:13 -0700
Subject: [Dwarf-Discuss] Any real products that do...
In-Reply-To: <4EA1AE24.5000308@eagercon.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
	<4EA05B26.6010301@roguewave.com>
	<FC0D83C633273A488E45F10E6CBCB46130EBE0B3@CAMEUREXM01.EUROPE.ROOT.PRI>
	<m3hb32i75j.fsf@fleche.redhat.com> <4EA1AE24.5000308@eagercon.com>
Message-ID: <D1BAD207-DBA4-47A2-BCAA-50077A667E3C@oracle.com>


Well he said "in the debuginfo" but I assume he means "in dwarf".
So that would include the linetable as well.  The significant bloat
for column information is in the line table and it's a very large
percentage increase for accurate information.  Especially for
optimized code.


On Friday October 21, at    10:38AM, Michael Eager wrote:

> On 10/21/2011 10:30 AM, Tom Tromey wrote:
>>>>>>> "David" == David Earlam<David.Earlam at csr.com>  writes:
>> 
>>>>>     Are there any existing DWARF-based tool chains (compiler and
>>>>> debugger) that use column information to do, say, highlight the
>>>>> fragments of a for statement as execution advances?
>> 
>> David>  xRay, ASPEX and RealView Debugger would draw a box around column
>> David>  delimited statements in a single line and ARM's RealView Compilation
>> David>  Tools 3 and 4
>> David>  compilers produce column information to let it do so.
>> 
>> I'm curious if you, or anybody, knows the space penalty for including
>> the column information in the debuginfo.  GCC could emit it pretty
>> easily, but I know people worry about size.
> 
> I think it would be one or two bytes for each TAG which has source coordinates.
> 
> -- 
> Michael Eager	 eager at eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org




From jmolenda@apple.com  Mon Oct 24 01:32:38 2011
From: jmolenda@apple.com (Jason Molenda)
Date: Sun, 23 Oct 2011 18:32:38 -0700
Subject: [Dwarf-Discuss] Any real products that do...
In-Reply-To: <D1BAD207-DBA4-47A2-BCAA-50077A667E3C@oracle.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
	<4EA05B26.6010301@roguewave.com>
	<FC0D83C633273A488E45F10E6CBCB46130EBE0B3@CAMEUREXM01.EUROPE.ROOT.PRI>
	<m3hb32i75j.fsf@fleche.redhat.com> <4EA1AE24.5000308@eagercon.com>
	<D1BAD207-DBA4-47A2-BCAA-50077A667E3C@oracle.com>
Message-ID: <DAAA6153-74D3-4158-9ABF-601AC3EED4F7@apple.com>


On Oct 23, 2011, at 5:35 PM, Chris Quenelle wrote:

> 
> Well he said "in the debuginfo" but I assume he means "in dwarf".
> So that would include the linetable as well.  The significant bloat
> for column information is in the line table and it's a very large
> percentage increase for accurate information.  Especially for
> optimized code.


Although a typical C++ program these days will have a debug_info around 100x larger than a debug_line (based on a single C++ framework I just checked at random, without type uniquing, compiled by llvm-gcc).  I'm sure this 100x number will vary a lot depending on what compiler you pick, whether you unique all the type definitions, which compiler it is, etc., but I don't think the line table is a significant source of bloat in the dwarf these days.  If it the size of debug_line doubled to incorporate good column information, I think there are many people who would accept that tradeoff.

J



From chris.quenelle@oracle.com  Mon Oct 24 02:14:29 2011
From: chris.quenelle@oracle.com (Chris Quenelle)
Date: Sun, 23 Oct 2011 19:14:29 -0700
Subject: [Dwarf-Discuss] Any real products that do...
In-Reply-To: <DAAA6153-74D3-4158-9ABF-601AC3EED4F7@apple.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF052DA8C3AD@sausexmbp02.amd.com>
	<4EA05B26.6010301@roguewave.com>
	<FC0D83C633273A488E45F10E6CBCB46130EBE0B3@CAMEUREXM01.EUROPE.ROOT.PRI>
	<m3hb32i75j.fsf@fleche.redhat.com> <4EA1AE24.5000308@eagercon.com>
	<D1BAD207-DBA4-47A2-BCAA-50077A667E3C@oracle.com>
	<DAAA6153-74D3-4158-9ABF-601AC3EED4F7@apple.com>
Message-ID: <3246ABCC-9F68-40DE-8063-1B52F5DBDF99@oracle.com>


On Sunday October 23, at    6:32PM, Jason Molenda wrote:

> 
> On Oct 23, 2011, at 5:35 PM, Chris Quenelle wrote:
> 
>> 
>> Well he said "in the debuginfo" but I assume he means "in dwarf".
>> So that would include the linetable as well.  The significant bloat
>> for column information is in the line table and it's a very large
>> percentage increase for accurate information.  Especially for
>> optimized code.
> 
> 
> Although a typical C++ program these days will have a debug_info around 100x larger than a debug_line (based on a single C++ framework I just checked at random, without type uniquing, compiled by llvm-gcc).  I'm sure this 100x number will vary a lot depending on what compiler you pick, whether you unique all the type definitions, which compiler it is, etc., but I don't think the line table is a significant source of bloat in the dwarf these days.  If it the size of debug_line doubled to incorporate good column information, I think there are many people who would accept that tradeoff.
> 
> J


I certainly wouldn't hold my wild guess above anyone who was willing to try it and see.  :-)
You could make a guess at the impact by looking at the line table for a segment
of code, and extrapolating from that.

I have to agree 100% with the idea that the biggest "dwarf bloat" problem is related
to "debug info".   Also note that type info is amenable to forms of commonization, but the
line table is not.

I just wanted to make sure the line table got factored into the equation.

--chris




From john.e.bishop@intel.com  Mon Oct 24 20:44:42 2011
From: john.e.bishop@intel.com (Bishop, John E)
Date: Mon, 24 Oct 2011 13:44:42 -0700
Subject: [Dwarf-Discuss] Any real products that do... [ Dwarf-Discuss
 Digest, Vol 53, Issue 3]
In-Reply-To: <mailman.1.1319217688.26250.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
References: <mailman.1.1319217688.26250.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
Message-ID: <8E3C37676DCD474C90755A75002439A20149822698@orsmsx506.amr.corp.intel.com>

"Relph, Richard" asks

> Are there any existing DWARF-based tool chains (compiler and debugger) that use
> column information to do, say, highlight the fragments of a for statement as 
> execution advances?

Yes, Intel's IDB could do this in the past.  It would highlight the part of a line which was where a breakpoint had hit.  The feature didn't get much use but was tested in the regression test system.
That support may have been lost due to bit-rot or the change in personel (I know other features have been lost since I was moved off IDB in early 2009).

I seem to recall that IDB's predecessor (Digital's "Ladebug") showed column information as well though it used COFF rather than DWARF and I last worked on Ladebug six years ago.

	-John


From john.e.bishop@intel.com  Mon Oct 24 21:31:43 2011
From: john.e.bishop@intel.com (Bishop, John E)
Date: Mon, 24 Oct 2011 14:31:43 -0700
Subject: [Dwarf-Discuss] Size cost of debug info [from Dwarf-Discuss
 Digest, Vol 52, Issue 7]
In-Reply-To: <mailman.2714.1316738353.15058.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
References: <mailman.2714.1316738353.15058.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
Message-ID: <8E3C37676DCD474C90755A75002439A201498226E9@orsmsx506.amr.corp.intel.com>

Cary Coutant says:

[begin quote]
At Google, we've found that the cost of linking applications with
debug info is much too high. A large C++ application that might be,
say, 200MB without debug info, is somewhere around 1GB with debug
info, and the total size of the object files that we send to the
linker is around 5GB (and that's with compressed debug sections).
We've come to the conclusion that the most promising solution is to
eliminate the debug info from the link step. I've had direct
experience with HP's approach to this, and I've looked into Sun's and
Apple's approaches, but none of those three approaches actually
separates the debug info from the non-debug info at the object file
(.o) level. I know we're not alone in having concerns about the size
of debug info, so we've developed the following proposal to extend the
DWARF format and produce separate .o and ".dwo" (DWARF object) files
at the compilation step. Our plan is to develop the gcc and gdb
changes on new upstream branches.
[end quote]

I don't see a problem which cries out to be solved.  My experience must be different from Cary's.

As far as I know the size of the debug information has never been a problem for any of the developers on any of the projects I've known over my working lifetime.  That lifetime covers a lot of different platforms and different formats of debug information (PDP-11, VAX, Alpha, HPUX, Intel; RSX, VMS, Tru64, HPUX, Linux; stabs, coff, DWARF).

When as a developer on Intel's IDB I had to make IDB handle Apple's attempts to leaving the debug information in the .o files.  I thought this was a mistake then.  I think it's a mistake now.  Memory is cheap.  Disks hold gigabytes.  Anyone doing debugging is going to have a big disk.

I build my curent project (the Fortran run-time library) with debug information and didn't even know what the impact is until just now because it's never mattered.  As a test, I just built with and without debug information on x86 Linux.  One library is 318 k-bytes without debug information and 874 k-bypes with debug information.  That's not even 3x.  Other libraries I just checked were about the same (between 2x and 3x).

The idea of .o/.dDSYM caching of debug information elsewhere brings up all the issues of matching and being out of date which are naturally avoided by having the debug information in the executable.

    -John


From brobecker@adacore.com  Mon Oct 24 21:52:11 2011
From: brobecker@adacore.com (Joel Brobecker)
Date: Mon, 24 Oct 2011 14:52:11 -0700
Subject: [Dwarf-Discuss] Size cost of debug info [from Dwarf-Discuss
 Digest, Vol 52, Issue 7]
In-Reply-To: <8E3C37676DCD474C90755A75002439A201498226E9@orsmsx506.amr.corp.intel.com>
References: <mailman.2714.1316738353.15058.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
	<8E3C37676DCD474C90755A75002439A201498226E9@orsmsx506.amr.corp.intel.com>
Message-ID: <20111024215211.GQ335@adacore.com>

> I don't see a problem which cries out to be solved.  My experience
> must be different from Cary's.

Our own experience is very similar to Cary's, and we have been
contacted by a few customers because of that. Our own rule of thumb
is that debugging info is about 10 times the size of the actual
executable. A lot of it is because of mindless duplication.

Memory and disk space may be cheap, but the time it takes to read
large amounts of data, only to write them back, can be quite a bit
of a time waster. Imagine you're working on a large project, you
modify one tiny file, recompile it (instantaneous), then spend
a long time waiting for the link to finish.  Even in the best
conditions, when you have 200 engineers doing that all day, you're
losing a lot of money.

That being said, I am not sure that there is anything that needs
to be addressed at the DWARF reference level. DWARF already helps
trying to compress a bit the amount of data required to encode
the info we want to store. We can, on the other hand, have
significant gains by eliminating the duplication, and/or leaving
the debug info in the .o files (I really dislike needing the .o
files for debugging, but you have to admit that it significantly
reduces the size of the exe). Google has some other ideas which
sound very promising as well.

-- 
Joel



From Richard.Relph@amd.com  Mon Oct 31 17:30:56 2011
From: Richard.Relph@amd.com (Relph, Richard)
Date: Mon, 31 Oct 2011 12:30:56 -0500
Subject: [Dwarf-Discuss] Vector base types...
Message-ID: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B3958A@sausexmbp02.amd.com>

Is there a convention for representing vector base types in a language?
Our language (OpenCL) has 2, 3, 4, 8, and 16 element vectors of each of the normal C base types and we're currently representing them in an ad hoc way. We'd like to follow whatever convention exists for doing this, but we haven't figured out what that is. Setting DW_AT_byte_size to the size of one element begs the question of how many, and setting it to the size of the type itself is ambiguous (unless you peek at the name... which we are resisting, though perhaps that "right way".) A char4, short2, and int all have 4 bytes and the same encoding.
We do have a DW_LANG value for OpenCL...

Thanks,
Richard
PS. Thanks for the many replies to the question about column number usage...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111031/3454ca7c/attachment.htm>


From John.DelSignore@roguewave.com  Mon Oct 31 18:15:40 2011
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Mon, 31 Oct 2011 14:15:40 -0400
Subject: [Dwarf-Discuss] Vector base types...
In-Reply-To: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B3958A@sausexmbp02.amd.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B3958A@sausexmbp02.amd.com>
Message-ID: <4EAEE5CC.5000501@roguewave.com>

I'm not sure you can consider this a "convention", but the GNU compiler seems to do the following for the Cell SPU vector types...

For example, "dt_v" is a parameter of type 4 vector floats:

 <2><233>: Abbrev Number: 12 (DW_TAG_formal_parameter)
     DW_AT_name        : dt_v	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 78	
     DW_AT_type        : <1bf>	
     DW_AT_location    : 2 byte block: 91 70 	(DW_OP_fbreg: -16)

The vector type is represented as an array with an upper bound of 3 with the DW_AT_GNU_vector attribute:

 <1><1bf>: Abbrev Number: 7 (DW_TAG_array_type)
     DW_AT_sibling     : <1d0>	
     DW_AT_GNU_vector  : 1	
     DW_AT_type        : <14c>	
 <2><1c9>: Abbrev Number: 8 (DW_TAG_subrange_type)
     DW_AT_type        : <ad>	
     DW_AT_upper_bound : 3	

The type of the index is unsigned long:

 <1><ad>: Abbrev Number: 2 (DW_TAG_base_type)
     DW_AT_name        : (indirect string, offset: 0x9): long unsigned int	
     DW_AT_byte_size   : 4	
     DW_AT_encoding    : 7	(unsigned)

The base type of the array is float:

 <1><14c>: Abbrev Number: 3 (DW_TAG_base_type)
     DW_AT_name        : float	
     DW_AT_byte_size   : 4	
     DW_AT_encoding    : 4	(float)

AFAICT, the only difference between the above and a "normal" array of 4 floats, is that the vector array type has the DW_AT_GNU_vector attribute.

Cheers, John D.


Relph, Richard wrote:
> Is there a convention for representing vector base types in a language?
> 
> Our language (OpenCL) has 2, 3, 4, 8, and 16 element vectors of each of
> the normal C base types and we?re currently representing them in an ad
> hoc way. We?d like to follow whatever convention exists for doing this,
> but we haven?t figured out what that is. Setting DW_AT_byte_size to the
> size of one element begs the question of how many, and setting it to the
> size of the type itself is ambiguous (unless you peek at the name? which
> we are resisting, though perhaps that ?right way?.) A char4, short2, and
> int all have 4 bytes and the same encoding.
> 
> We do have a DW_LANG value for OpenCL?
> 
>  
> 
> Thanks,
> 
> Richard
> 
> PS. Thanks for the many replies to the question about column number usage?
> 



From eager@eagercon.com  Mon Oct 31 18:17:51 2011
From: eager@eagercon.com (Michael Eager)
Date: Mon, 31 Oct 2011 11:17:51 -0700
Subject: [Dwarf-Discuss] Vector base types...
In-Reply-To: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B3958A@sausexmbp02.amd.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B3958A@sausexmbp02.amd.com>
Message-ID: <4EAEE64F.4080504@eagercon.com>

On 10/31/2011 10:30 AM, Relph, Richard wrote:
> Is there a convention for representing vector base types in a language?
>
> Our language (OpenCL) has 2, 3, 4, 8, and 16 element vectors of each of the normal C base types and
> we?re currently representing them in an ad hoc way. We?d like to follow whatever convention exists
> for doing this, but we haven?t figured out what that is. Setting DW_AT_byte_size to the size of one
> element begs the question of how many, and setting it to the size of the type itself is ambiguous
> (unless you peek at the name? which we are resisting, though perhaps that ?right way?.) A char4,
> short2, and int all have 4 bytes and the same encoding.

Is there a functional difference between an array and a vector?

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077




From eager@eagercon.com  Mon Oct 31 18:20:22 2011
From: eager@eagercon.com (Michael Eager)
Date: Mon, 31 Oct 2011 11:20:22 -0700
Subject: [Dwarf-Discuss] Vector base types...
In-Reply-To: <4EAEE5CC.5000501@roguewave.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B3958A@sausexmbp02.amd.com>
	<4EAEE5CC.5000501@roguewave.com>
Message-ID: <4EAEE6E6.3010406@eagercon.com>

On 10/31/2011 11:15 AM, John DelSignore wrote:

> AFAICT, the only difference between the above and a "normal" array of 4 floats, is that the vector array type has the DW_AT_GNU_vector attribute.

What is that supposed to mean?  Print "vector int foo" instead
of "int foo[4]"?

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



From Richard.Relph@amd.com  Mon Oct 31 18:44:03 2011
From: Richard.Relph@amd.com (Relph, Richard)
Date: Mon, 31 Oct 2011 13:44:03 -0500
Subject: [Dwarf-Discuss] Vector base types...
In-Reply-To: <4EAEE64F.4080504@eagercon.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B3958A@sausexmbp02.amd.com>
	<4EAEE64F.4080504@eagercon.com>
Message-ID: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B39637@sausexmbp02.amd.com>

In OpenCL, of course. You can access a variable (v) of vector type (float16) in several different ways, subsetting the members of the vector being accessed. v.s0 is the first element (as is v.x), v.lo is the first 8 elements, v.hi is the last 8 elements, v.odd is elements 1,3,5, etc. and v.even is the even elements.
In memory, there are alignment restrictions that apply to float16 that don't apply to an array of floats. The required alignment of the latter is the same as for float (4 bytes), while the alignment of the former could be as bad as the size of a single float16 (64 bytes).
Other than that, no differences that I can think of.
The debugger is looking for a way (short of name recognition) to know which access methods apply to a variable... DW_AT_GNU_vector may be an interesting 'flag' to differentiate an array from a vector. Does the value mean anything? I tried googling it, but haven't stumbled across the answer to that just yet.

-----Original Message-----
From: Michael Eager [mailto:eager@eagercon.com] 
Sent: Monday, October 31, 2011 11:18 AM
To: Relph, Richard
Cc: dwarf-discuss at lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] Vector base types...

On 10/31/2011 10:30 AM, Relph, Richard wrote:
> Is there a convention for representing vector base types in a language?
>
> Our language (OpenCL) has 2, 3, 4, 8, and 16 element vectors of each 
> of the normal C base types and we?re currently representing them in an 
> ad hoc way. We?d like to follow whatever convention exists for doing 
> this, but we haven?t figured out what that is. Setting DW_AT_byte_size 
> to the size of one element begs the question of how many, and setting 
> it to the size of the type itself is ambiguous (unless you peek at the name? which we are resisting, though perhaps that ?right way?.) A char4, short2, and int all have 4 bytes and the same encoding.

Is there a functional difference between an array and a vector?

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077




From eager@eagercon.com  Mon Oct 31 18:59:18 2011
From: eager@eagercon.com (Michael Eager)
Date: Mon, 31 Oct 2011 11:59:18 -0700
Subject: [Dwarf-Discuss] Vector base types...
In-Reply-To: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B39637@sausexmbp02.amd.com>
References: <7691DC9FC60C9E4F88A0BBCA628F55FF0540B3958A@sausexmbp02.amd.com>
	<4EAEE64F.4080504@eagercon.com>
	<7691DC9FC60C9E4F88A0BBCA628F55FF0540B39637@sausexmbp02.amd.com>
Message-ID: <4EAEF006.9070406@eagercon.com>

On 10/31/2011 11:44 AM, Relph, Richard wrote:
> In OpenCL, of course. You can access a variable (v) of vector type (float16) in several different
> ways, subsetting the members of the vector being accessed. v.s0 is the first element (as is v.x),
> v.lo is the first 8 elements, v.hi is the last 8 elements, v.odd is elements 1,3,5, etc. and
> v.even is the even elements.

I'm not familiar with OpenCL.  If these operations are not permitted on arrays,
then an attribute flag would tell the debugger whether to interpret v.s0 as a
reference to v[0] or to issue an error message.

 > In memory, there are alignment restrictions that apply to float16
> that don't apply to an array of floats. The required alignment of the latter is the same as for
> float (4 bytes), while the alignment of the former could be as bad as the size of a single
> float16 (64 bytes).

Allocation restrictions are usually only known to the compiler and not represented in DWARF.

 > Other than that, no differences that I can think of. The debugger is looking
> for a way (short of name recognition) to know which access methods apply to a variable...
> DW_AT_GNU_vector may be an interesting 'flag' to differentiate an array from a vector. Does the
> value mean anything? I tried googling it, but haven't stumbled across the answer to that just
> yet.
>
> -----Original Message----- From: Michael Eager [mailto:eager at eagercon.com] Sent: Monday, October
> 31, 2011 11:18 AM To: Relph, Richard Cc: dwarf-discuss at lists.dwarfstd.org Subject: Re:
> [Dwarf-Discuss] Vector base types...
>
> On 10/31/2011 10:30 AM, Relph, Richard wrote:
>> Is there a convention for representing vector base types in a language?
>>
>> Our language (OpenCL) has 2, 3, 4, 8, and 16 element vectors of each of the normal C base types
>> and we?re currently representing them in an ad hoc way. We?d like to follow whatever convention
>> exists for doing this, but we haven?t figured out what that is. Setting DW_AT_byte_size to the
>> size of one element begs the question of how many, and setting it to the size of the type
>> itself is ambiguous (unless you peek at the name? which we are resisting, though perhaps that
>> ?right way?.) A char4, short2, and int all have 4 bytes and the same encoding.
>
> Is there a functional difference between an array and a vector?
>


-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077




