From xiexs@cn.fujitsu.com  Mon Jul  9 08:28:58 2012
From: xiexs@cn.fujitsu.com (Xie Xianshan)
Date: Mon, 09 Jul 2012 16:28:58 +0800
Subject: [Dwarf-Discuss] How to create multiple CUs in a single creation
Message-ID: <4FFA964A.7060907@cn.fujitsu.com>

Hi All,
 
  I`m trying to generate my own dwarf files with libdwarf API.
But i don`t know how to create multiple complication units in a single 
creation.
  I`ve tried to call dwarf_new_die(dbg,DW_TAG_compile_unit,...) twice,
but there was only one CU header generated(two DW_TAG_compile_unit 
tag),as follows:
----------------------------
  Compilation Unit @ 0:
   Length:        170
   Version:       2
   Abbrev Offset: 0
   Pointer Size:  4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_producer    : GNU C 4.6.12
     DW_AT_name        : test.c
     DW_AT_comp_dir    : /home/work/
     DW_AT_ranges      : 0
     DW_AT_stmt_list   : 0
 <1><34>: Abbrev Number: 2 (DW_TAG_subprogram)
<0><47>: Abbrev Number: 4 (DW_TAG_compile_unit)
----------------------------
Does anybody  have experience to this?

Thanks in advance for any advice.
Simen






From davea42@earthlink.net  Mon Jul  9 14:18:40 2012
From: davea42@earthlink.net (David Anderson)
Date: Mon, 09 Jul 2012 07:18:40 -0700
Subject: [Dwarf-Discuss] How to create multiple CUs in a single creation
In-Reply-To: <4FFA964A.7060907@cn.fujitsu.com>
References: <4FFA964A.7060907@cn.fujitsu.com>
Message-ID: <4FFAE840.4020604@earthlink.net>

On 07/09/2012 01:28 AM, Xie Xianshan wrote:
> Hi All,
>
>  I`m trying to generate my own dwarf files with libdwarf API.
> But i don`t know how to create multiple complication units in a single 
> creation.
>  I`ve tried to call dwarf_new_die(dbg,DW_TAG_compile_unit,...) twice,
> but there was only one CU header generated(two DW_TAG_compile_unit 
> tag),as follows:
> ----------------------------
>  Compilation Unit @ 0:
>   Length:        170
>   Version:       2
>   Abbrev Offset: 0
>   Pointer Size:  4
> <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     DW_AT_producer    : GNU C 4.6.12
>     DW_AT_name        : test.c
>     DW_AT_comp_dir    : /home/work/
>     DW_AT_ranges      : 0
>     DW_AT_stmt_list   : 0
> <1><34>: Abbrev Number: 2 (DW_TAG_subprogram)
> <0><47>: Abbrev Number: 4 (DW_TAG_compile_unit)
> ----------------------------
> Does anybody  have experience to this?


libdwarf was not designed to prepare multiple CUs in a single creation. 
Sorry.
There is nothing inherent in DWARF or libdwarf preventing such, of course.
And clearly libdwarf needs updating on this point.   But libdwarf cannot do
what you ask in a single  producer dwarf-init call --- at present.

Libdwarf can really only produce DWARF2 output at the moment as well.
Another serious weakness.    While I've been working on the producer
code for some time, progress has been slow, what with other tasks in life.
Again, sorry.

David Anderson


-- 
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?




From xiexs@cn.fujitsu.com  Wed Jul 11 13:26:41 2012
From: xiexs@cn.fujitsu.com (Xie Xianshan)
Date: Wed, 11 Jul 2012 21:26:41 +0800
Subject: [Dwarf-Discuss] How to create multiple CUs in a single creation
In-Reply-To: <4FFAE840.4020604@earthlink.net>
References: <4FFA964A.7060907@cn.fujitsu.com> <4FFAE840.4020604@earthlink.net>
Message-ID: <4FFD7F11.9000501@cn.fujitsu.com>

@David and @Andrew.
Thanks for your quick response.
I`ll be wating for your good news,and  i`ll try other way of making it now.
Thanks again.

Simen

David Anderson wrote:
> On 07/09/2012 01:28 AM, Xie Xianshan wrote:
>> Hi All,
>>
>>  I`m trying to generate my own dwarf files with libdwarf API.
>> But i don`t know how to create multiple complication units in a 
>> single creation.
>>  I`ve tried to call dwarf_new_die(dbg,DW_TAG_compile_unit,...) twice,
>> but there was only one CU header generated(two DW_TAG_compile_unit 
>> tag),as follows:
>> ----------------------------
>>  Compilation Unit @ 0:
>>   Length:        170
>>   Version:       2
>>   Abbrev Offset: 0
>>   Pointer Size:  4
>> <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>>     DW_AT_producer    : GNU C 4.6.12
>>     DW_AT_name        : test.c
>>     DW_AT_comp_dir    : /home/work/
>>     DW_AT_ranges      : 0
>>     DW_AT_stmt_list   : 0
>> <1><34>: Abbrev Number: 2 (DW_TAG_subprogram)
>> <0><47>: Abbrev Number: 4 (DW_TAG_compile_unit)
>> ----------------------------
>> Does anybody  have experience to this?
>
>
> libdwarf was not designed to prepare multiple CUs in a single 
> creation. Sorry.
> There is nothing inherent in DWARF or libdwarf preventing such, of 
> course.
> And clearly libdwarf needs updating on this point.   But libdwarf 
> cannot do
> what you ask in a single  producer dwarf-init call --- at present.
>
> Libdwarf can really only produce DWARF2 output at the moment as well.
> Another serious weakness.    While I've been working on the producer
> code for some time, progress has been slow, what with other tasks in 
> life.
> Again, sorry.
>
> David Anderson
>
>


-- 
Best Regards
Xie Xianshan
--------------------------------------------------
Xie Xianshan
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu Road, Nanjing, 210012, China
PHONE: +86+25-86630566-8517
FUJITSU INTERNAL: 7998-8517
MAIL: xiexs at cn.fujitsu.com
--------------------------------------------------
This communication is for use by the intended recipient(s) only and may
contain information that is privileged, confidential and exempt from
disclosure under applicable law. If you are not an intended recipient of
this communication, you are hereby notified that any dissemination,
distribution or copying hereof is strictly prohibited.  If you have
received this communication in error, please notify me by reply e-mail,
permanently delete this communication from your system, and destroy any
hard copies you may have printed 




From mjw@redhat.com  Thu Jul 19 13:28:15 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Thu, 19 Jul 2012 15:28:15 +0200
Subject: [Dwarf-Discuss] DW_AT_entry_pc vs DW_AT_ranges
In-Reply-To: <20120515182958.GA22611@toonder.wildebeest.org>
References: <1335959214.24235.62.camel@springer.wildebeest.org>
	<20120515182958.GA22611@toonder.wildebeest.org>
Message-ID: <1342704495.16063.30.camel@springer.wildebeest.org>

On Tue, 2012-05-15 at 20:29 +0200, Mark Wielaard wrote:
> I got one off-list reply to the second suggestion, adding that having
> a constant form could also be added so it is an offset relative to the
> first pc of the range.
> 
> Does it make sense to write up an proposal for the second part?
> I could also hack up a GCC patch for it, to better show the impact
> if that would help.

I got some more feedback offlist saying that it would be nice to have a
proposal. I got somewhat distracted by other things and didn't think the
savings were too great. But I learned that even the DW_AT_low_pc
encoding change was found to be a win. That reduced the number of
relocation addresses with just 2%. A quick test showed changing
DW_AT_entry_pc in the same way saves another 1% of relocatable addresses
in the DWARF data. That isn't much, but I guess every percentage counts.

So here is a more formal proposal. Also submitted through
http://dwarfstd.org/SubmitComment.php, but it isn't yet showing up on
http://dwarfstd.org/Issues.php.

Background:

Currently, an DIE with a DW_AT_entry_pc and a DW_AT_ranges will create
multiple relocatable addresses for both the DW_AT_entry_pc and the
DW_AT_ranges. For example:

In .debug_info

DW_TAG_subroutine
  DW_AT_entry_pc (addr) 0x403a9e <func+0x1e>
  DW_AT_ranges (sec_offset) range list [    50]

In .debug_ranges

[50] 0x403a9e <some_func+0x1e>..0x403aa4 <some_func+0x24>
     0x403abb <some_func+0x3b>..0x403abf <some_func+0x3f>

Often, as in this example, the entry_pc is equal to the first range
address.

Proposal:

Since DW_AT_entry_pc is often the same, or an offset from, the first
range list address, it can be encoded as either a flag value signaling
that the DW_AT_entry_pc value is equal to the first DW_AT_ranges
address, or be encoded as a constant offset from the first
DW_AT_ranges address.

Wording changes:

2.18 Entry Address

Remove the '.' the end of the sentence "The value of the
DW_AT_entry_pc attribute is a relocated address" and add "if the
value of DW_AT_entry_pc is of class address; or if it is of class
flag, then the value true indicates it is the same as the first
address in the range of code addresses; or if it is of class constant,
the value is an unsigned integer offset which when added to the first
address in the range of code addresses gives the entry address."

Figure 20. Attribute encodings, begins here.

Change the entry for DW_AT_entry_pc to read:

DW_AT_entry_pc   0x52   address, flag, constant



From mjw@redhat.com  Thu Jul 19 13:38:13 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Thu, 19 Jul 2012 15:38:13 +0200
Subject: [Dwarf-Discuss] gmane gateway/archive
Message-ID: <1342705093.16063.34.camel@springer.wildebeest.org>

Hi,

I submitted dwarf-discuss at lists.dwarfstd.org as list to be included on
gmane. Hopefully it will show up soon as
gmane.comp.standards.dwarf-discuss. gmane is a mailing list archive that
provides an NNTP gateway and RSS/Atom feeds that make it easy to find
various public discussions. See http://gmane.org/ Hope this makes the
DWARF standard work easier to find and access.

Cheers,

Mark



From mjw@redhat.com  Fri Jul 20 10:20:53 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Fri, 20 Jul 2012 12:20:53 +0200
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
Message-ID: <1342779653.30850.4.camel@springer.wildebeest.org>

Hi,

I noticed GCC already outputs the proposed DW_LANG_Go from
http://dwarfstd.org/ShowIssue.php?issue=101014.1
I assume there are other such smaller/constants changes that are just OK
without needing a major DWARF spec revision. Is there a list of such
preliminary accepted issues/updates/constants?

Thanks,

Mark



From ron.brender@gmail.com  Fri Jul 20 13:37:56 2012
From: ron.brender@gmail.com (Ron Brender)
Date: Fri, 20 Jul 2012 09:37:56 -0400
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <1342779653.30850.4.camel@springer.wildebeest.org>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
Message-ID: <CANSbVTgnDJPcjnWapR+vzuOxk-kv8J3Ru4UttEQR3G342wAMDQ@mail.gmail.com>

Your assumption is not justified. Use of any proposed, or even
"adopted", extension by an implementation is strictly *own risk*.
There is a well-defined implementation defined extension mechanism
that provides an alternative..

Note that the status of the DWARF issue you mention is "open" -- that
is, it is not even adopted yet.

The DWARF V5 revision effort is just getting underway. While a few
minor changes have been discussed and approved *in principle*, none
has yet to be codified into even a draft revised specification.

Ron

---------------------------------------------------------------------------------------------
On Fri, Jul 20, 2012 at 6:20 AM, Mark Wielaard <mjw at redhat.com> wrote:
> Hi,
>
> I noticed GCC already outputs the proposed DW_LANG_Go from
> http://dwarfstd.org/ShowIssue.php?issue=101014.1
> I assume there are other such smaller/constants changes that are just OK
> without needing a major DWARF spec revision. Is there a list of such
> preliminary accepted issues/updates/constants?
>
> Thanks,
>
> Mark
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



From iant@google.com  Fri Jul 20 13:52:20 2012
From: iant@google.com (Ian Lance Taylor)
Date: Fri, 20 Jul 2012 06:52:20 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <1342779653.30850.4.camel@springer.wildebeest.org>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
Message-ID: <CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>

On Fri, Jul 20, 2012 at 3:20 AM, Mark Wielaard <mjw at redhat.com> wrote:
>
> I noticed GCC already outputs the proposed DW_LANG_Go from
> http://dwarfstd.org/ShowIssue.php?issue=101014.1
> I assume there are other such smaller/constants changes that are just OK
> without needing a major DWARF spec revision. Is there a list of such
> preliminary accepted issues/updates/constants?

The DW_LANG_Go constant was discussed on dwarf-discuss in October
2010.  I filed an issue at
http://dwarfstd.org/ShowIssue.php?issue=101014.1&type=open .  In the
October 2010 I asked whether it would be OK to use the provisionally
assigned value, and Michael Eager said "Should be OK."

GCC will use the provisionally assigned value for DW_LANG_Go only when
directed to emit DWARF version 5 or when using -gno-strict-dwarf
(which is the default).  That is, when using -gstrict-dwarf with a
version of DWARF less than 5, GCC will not emit DW_LANG_Go.

It's clear that this is at GCC's own risk.

Ian



From ccoutant@gmail.com  Fri Jul 20 18:46:38 2012
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 20 Jul 2012 11:46:38 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
Message-ID: <CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>

For things like new tags, attributes, language codes, etc., we have
occasionally given out assurances that the assigned numbers were safe
to use once discussion was complete and the issue was accepted. In
most cases, it's then OK to use these without bumping the DWARF
version number, since clients are supposed to be able to tolerate
unknown values (although binutils is a notable exception). For
DW_LANG_Go, we did in fact issue such an assurance. (I don't even
think it was necessary to qualify its use under -gstrict-dwarf, since
there's no decent alternative for you to use for Go debug info.)

If DWARF 5 had included nothing new but a few new tags, attributes,
and language codes, we would have had no reason to change the version
number.

New form codes, however, and changes to any of the various compilation
unit headers, always require a new DWARF version number. The consumer
needs to be able to recognize all form codes or it won't be able to
parse the debug info properly, and clearly it needs to understand the
structure of the compilation unit headers for each debug section.

For a long time, in fact, GCC was generating many tags and attributes
from the DWARF-3 spec, while still conforming to the DWARF-2 spec in
terms of header structures and form codes.

-cary



From eager@eagerm.com  Fri Jul 20 19:53:55 2012
From: eager@eagerm.com (Michael Eager)
Date: Fri, 20 Jul 2012 12:53:55 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
Message-ID: <5009B753.3030706@eagerm.com>

On 07/20/2012 11:46 AM, Cary Coutant wrote:
> For things like new tags, attributes, language codes, etc., we have
> occasionally given out assurances that the assigned numbers were safe
> to use once discussion was complete and the issue was accepted. In
> most cases, it's then OK to use these without bumping the DWARF
> version number, since clients are supposed to be able to tolerate
> unknown values (although binutils is a notable exception). For
> DW_LANG_Go, we did in fact issue such an assurance.

The DWARF Committee does give any assurances that any proposal will be
accepted, or that any proposal will be accepted without modification.
As Ron pointed out, only a released DWARF specification can be
considered authoritative.  No assurance was given with regard to any
proposal for adoption in DWARF Version 5, nor has any ever been given
prior to previous versions of the DWARF standard being released.

As Ian mentioned, when I indicated "Should be OK", that is not an
assurance that the assignment of a value for DW_LANG_Go would be
accepted as proposed, only that I thought that it was likely.  As Ian
said, reliance on this opinion is taken at GCC's risk.

DWARF contains facilities for user extensions and we encourage
compiler developers to use this methodology.  If developers decide,
for whatever reason, to not use the extension facilities built
into DWARF, there is a risk that they will have reverse or modify
this decision at some future date.  That said, we are cognizant of
these changes and will try to accommodate them, but we make no
guarantee or assurances that this will happen.

I hope this clarifies this question.


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





From fche@redhat.com  Fri Jul 20 19:56:34 2012
From: fche@redhat.com (Frank Ch. Eigler)
Date: Fri, 20 Jul 2012 15:56:34 -0400
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <5009B753.3030706@eagerm.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com>
Message-ID: <20120720195634.GC6331@redhat.com>

Hi -

On Fri, Jul 20, 2012 at 12:53:55PM -0700, Michael Eager wrote:
> [...]
> The DWARF Committee does give any assurances that any proposal will be
> accepted, or that any proposal will be accepted without modification.
> [...]

That makes sense.

> As Ian mentioned, when I indicated "Should be OK", that is not an
> assurance that the assignment of a value for DW_LANG_Go would be
> accepted as proposed, only that I thought that it was likely.  [...]

Would the committee consider a faster-track number-assignment process,
kind of like IANA, for proposals that do not constitute material
structural changes to DWARF, but mere non-conflicting assignment of
magic numbers?

- FChE



From ccoutant@gmail.com  Fri Jul 20 20:24:13 2012
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 20 Jul 2012 13:24:13 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <5009B753.3030706@eagerm.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com>
Message-ID: <CAJimCsEu4L0F=X9nHkp3BU0Rb929B+rtNoCUYmrxna4xyQvQXQ@mail.gmail.com>

>> For things like new tags, attributes, language codes, etc., we have
>> occasionally given out assurances that the assigned numbers were safe
>> to use once discussion was complete and the issue was accepted. In
>> most cases, it's then OK to use these without bumping the DWARF
>> version number, since clients are supposed to be able to tolerate
>> unknown values (although binutils is a notable exception). For
>> DW_LANG_Go, we did in fact issue such an assurance.
>
> The DWARF Committee does give any assurances that any proposal will be
> accepted, or that any proposal will be accepted without modification.
> As Ron pointed out, only a released DWARF specification can be
> considered authoritative.  No assurance was given with regard to any
> proposal for adoption in DWARF Version 5, nor has any ever been given
> prior to previous versions of the DWARF standard being released.

I didn't say that we gave assurances in advance that proposals would
be accepted, or accepted without modification. I said that on occasion
-- once we had discussed, accepted, and closed the issue -- we had
given an assurance that the assigned numbers were firm. DW_LANG_Go, as
I recall, was one of these cases.

-cary



From mjw@redhat.com  Fri Jul 20 20:41:17 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Fri, 20 Jul 2012 22:41:17 +0200
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <20120720195634.GC6331@redhat.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com> <20120720195634.GC6331@redhat.com>
Message-ID: <20120720204114.GA26687@toonder.wildebeest.org>

On Fri, Jul 20, 2012 at 03:56:34PM -0400, Frank Ch. Eigler wrote:
> Would the committee consider a faster-track number-assignment process,
> kind of like IANA, for proposals that do not constitute material
> structural changes to DWARF, but mere non-conflicting assignment of
> magic numbers?

Yeah that sounds useful. My question assumed something like that
already existed for "non-controversial" extensions like new DW_LANG
constants. The vendor extension space can of course be used for this,
like for example is the case with DW_LANG_Mips_Assembler (0x8001) which
is adopted by other too to mean general assembly language. But the
downside to that is that we need some way to coordinate the vendor
space too. And once something is in vendor space and works it is
actually more work to then suggest it as a standard DWARF extension
because you need to add extra code paths/checks.

Cheers,

Mark



From eager@eagercon.com  Fri Jul 20 21:06:57 2012
From: eager@eagercon.com (Michael Eager)
Date: Fri, 20 Jul 2012 14:06:57 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <5009B753.3030706@eagerm.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com>
Message-ID: <5009C871.4060002@eagercon.com>

On 07/20/2012 12:53 PM, Michael Eager wrote:
> On 07/20/2012 11:46 AM, Cary Coutant wrote:
>> For things like new tags, attributes, language codes, etc., we have
>> occasionally given out assurances that the assigned numbers were safe
>> to use once discussion was complete and the issue was accepted. In
>> most cases, it's then OK to use these without bumping the DWARF
>> version number, since clients are supposed to be able to tolerate
>> unknown values (although binutils is a notable exception). For
>> DW_LANG_Go, we did in fact issue such an assurance.
>
> The DWARF Committee does give any assurances that any proposal will be
> accepted, or that any proposal will be accepted without modification.

Oops.  I read this four times, and it doesn't say what I meant:

The DWARF Committee does NOT give any assurances that any proposal will be
accepted, or that any proposal will be accepted without modification.

> As Ron pointed out, only a released DWARF specification can be
> considered authoritative.  No assurance was given with regard to any
> proposal for adoption in DWARF Version 5, nor has any ever been given
> prior to previous versions of the DWARF standard being released.
>
> As Ian mentioned, when I indicated "Should be OK", that is not an
> assurance that the assignment of a value for DW_LANG_Go would be
> accepted as proposed, only that I thought that it was likely.  As Ian
> said, reliance on this opinion is taken at GCC's risk.
>
> DWARF contains facilities for user extensions and we encourage
> compiler developers to use this methodology.  If developers decide,
> for whatever reason, to not use the extension facilities built
> into DWARF, there is a risk that they will have reverse or modify
> this decision at some future date.  That said, we are cognizant of
> these changes and will try to accommodate them, but we make no
> guarantee or assurances that this will happen.
>
> I hope this clarifies this question.
>
>


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





From eager@eagercon.com  Fri Jul 20 21:08:03 2012
From: eager@eagercon.com (Michael Eager)
Date: Fri, 20 Jul 2012 14:08:03 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <20120720195634.GC6331@redhat.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com> <20120720195634.GC6331@redhat.com>
Message-ID: <5009C8B3.5070204@eagercon.com>

On 07/20/2012 12:56 PM, Frank Ch. Eigler wrote:
> Hi -
>
> On Fri, Jul 20, 2012 at 12:53:55PM -0700, Michael Eager wrote:
>> [...]
>> The DWARF Committee does give any assurances that any proposal will be
>> accepted, or that any proposal will be accepted without modification.
>> [...]
>
> That makes sense.
>
>> As Ian mentioned, when I indicated "Should be OK", that is not an
>> assurance that the assignment of a value for DW_LANG_Go would be
>> accepted as proposed, only that I thought that it was likely.  [...]
>
> Would the committee consider a faster-track number-assignment process,
> kind of like IANA, for proposals that do not constitute material
> structural changes to DWARF, but mere non-conflicting assignment of
> magic numbers?

We don't want to have competing and conflicting standards procedures.
We have a simple low-overhead standards process.  Adding a fast-track
process would increase the complexity and increase overhead (i.e., my
time), and might lead to the awkward situation where the fast-track
consideration of a proposal and a more deliberative one disagree.

A proposal which has been approved by the committee (as shown on our
website) has a very high likelihood of being incorporated into the
released standard as written.  That's not a guarantee, though.

We encourage people to use the DWARF extension facility whenever possible,
rather than trying to anticipate future specifications.

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





From eager@eagerm.com  Fri Jul 20 21:12:11 2012
From: eager@eagerm.com (Michael Eager)
Date: Fri, 20 Jul 2012 14:12:11 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <CAJimCsEu4L0F=X9nHkp3BU0Rb929B+rtNoCUYmrxna4xyQvQXQ@mail.gmail.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com>
	<CAJimCsEu4L0F=X9nHkp3BU0Rb929B+rtNoCUYmrxna4xyQvQXQ@mail.gmail.com>
Message-ID: <5009C9AB.90502@eagerm.com>

On 07/20/2012 01:24 PM, Cary Coutant wrote:

> I didn't say that we gave assurances in advance that proposals would
> be accepted, or accepted without modification. I said that on occasion
> -- once we had discussed, accepted, and closed the issue -- we had
> given an assurance that the assigned numbers were firm. DW_LANG_Go, as
> I recall, was one of these cases.

No assurances were made in this case, nor with any other proposal.

Acceptance of a proposal is not a guarantee that it will be incorporated
into a future version of the standard without modification.

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





From Paul.Robinson@am.sony.com  Fri Jul 20 22:14:33 2012
From: Paul.Robinson@am.sony.com (Robinson, Paul)
Date: Fri, 20 Jul 2012 22:14:33 +0000
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <5009C8B3.5070204@eagercon.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com>
	<20120720195634.GC6331@redhat.com>,<5009C8B3.5070204@eagercon.com>
Message-ID: <380DDC5801D2BC41AB95DF407A939E350D8CB8DF@USCULXMSG03.am.sony.com>

Michael Eager wrote:
>On 07/20/2012 12:56 PM, Frank Ch. Eigler wrote:
>> [...]
>> Would the committee consider a faster-track number-assignment process,
>> kind of like IANA, for proposals that do not constitute material
>> structural changes to DWARF, but mere non-conflicting assignment of
>> magic numbers?
>
> We don't want to have competing and conflicting standards procedures.
> We have a simple low-overhead standards process.  Adding a fast-track
> process would increase the complexity and increase overhead (i.e., my
> time), and might lead to the awkward situation where the fast-track
> consideration of a proposal and a more deliberative one disagree.

I agree with Michael...

...except for the one specific case of language codes.

Language codes are a list of values that don't affect anything anywhere else
in the spec, with the single trivial exception of the default lower bound for
arrays, which is already incorporated into the language-code table.
I flipped through Chapter 7 and it's the only case like that, a list of numbers
that have no other syntactic implications and (almost) no semantic implications.

New language codes are rare, maybe 1 per year. No new language code 
request has been rejected, according to the resolved-issues lists.

The interval between publishing DWARF 3 and DWARF 4 was 5 years. 
I don't see any particular value in waiting 5 years to formally and officially
assign a name/number combination for a language code.
--paulr



From eager@eagerm.com  Fri Jul 20 22:58:32 2012
From: eager@eagerm.com (Michael Eager)
Date: Fri, 20 Jul 2012 15:58:32 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <380DDC5801D2BC41AB95DF407A939E350D8CB8DF@USCULXMSG03.am.sony.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com> <20120720195634.GC6331@redhat.com>,
	<5009C8B3.5070204@eagercon.com>
	<380DDC5801D2BC41AB95DF407A939E350D8CB8DF@USCULXMSG03.am.sony.com>
Message-ID: <5009E298.5050602@eagerm.com>

On 07/20/2012 03:14 PM, Robinson, Paul wrote:
> Michael Eager wrote:
>> On 07/20/2012 12:56 PM, Frank Ch. Eigler wrote:
>>> [...]
>>> Would the committee consider a faster-track number-assignment process,
>>> kind of like IANA, for proposals that do not constitute material
>>> structural changes to DWARF, but mere non-conflicting assignment of
>>> magic numbers?
>>
>> We don't want to have competing and conflicting standards procedures.
>> We have a simple low-overhead standards process.  Adding a fast-track
>> process would increase the complexity and increase overhead (i.e., my
>> time), and might lead to the awkward situation where the fast-track
>> consideration of a proposal and a more deliberative one disagree.
>
> I agree with Michael...
>
> ...except for the one specific case of language codes.
>
> Language codes are a list of values that don't affect anything anywhere else
> in the spec, with the single trivial exception of the default lower bound for
> arrays, which is already incorporated into the language-code table.
> I flipped through Chapter 7 and it's the only case like that, a list of numbers
> that have no other syntactic implications and (almost) no semantic implications.
>
> New language codes are rare, maybe 1 per year. No new language code
> request has been rejected, according to the resolved-issues lists.
>
> The interval between publishing DWARF 3 and DWARF 4 was 5 years.
> I don't see any particular value in waiting 5 years to formally and officially
> assign a name/number combination for a language code.

As said earlier, compiler developers can make their own choices
about whether to wait or to assume that there will be no changes.
With language codes, there's little risk in this assumption.

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





From ccoutant@gmail.com  Fri Jul 20 23:09:05 2012
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 20 Jul 2012 16:09:05 -0700
Subject: [Dwarf-Discuss] constants updates, minor DWARF standard upgrade?
In-Reply-To: <5009C9AB.90502@eagerm.com>
References: <1342779653.30850.4.camel@springer.wildebeest.org>
	<CAKOQZ8yOUbknEB99Os2R5G1EKT_P5LApdm3NYXMkYgkr4RGL7g@mail.gmail.com>
	<CAJimCsH_QtULfZF_Ssk+9GWqNnG+STZcoMMNUa6ui1xfx4Gw_A@mail.gmail.com>
	<5009B753.3030706@eagerm.com>
	<CAJimCsEu4L0F=X9nHkp3BU0Rb929B+rtNoCUYmrxna4xyQvQXQ@mail.gmail.com>
	<5009C9AB.90502@eagerm.com>
Message-ID: <CAJimCsH-wREseXpK+xafo3wz9K=iVpkgB6EXF6Zir6k1jCxJLw@mail.gmail.com>

>> I didn't say that we gave assurances in advance that proposals would
>> be accepted, or accepted without modification. I said that on occasion
>> -- once we had discussed, accepted, and closed the issue -- we had
>> given an assurance that the assigned numbers were firm. DW_LANG_Go, as
>> I recall, was one of these cases.
>
> No assurances were made in this case, nor with any other proposal.

Well, perhaps I was exceeding my authority, or we have a different
definition of "assurances", but I recall asking in a meeting whether
the assignment for Go was firm and could be used by Ian without fear
of collision. With Ron's confirmation that the new number had been
added to the draft document, I was confident enough to give the
go-ahead.

(The real danger here is that, until the document is published, we
might accidentally hand out the same number twice, if someone happens
to be looking at an older draft. I wouldn't have made any assurance
until Ron had actually added it to the current draft.)

-cary



From joeri@ace.nl  Thu Jul 26 05:45:48 2012
From: joeri@ace.nl (Joeri van Ruth)
Date: Thu, 26 Jul 2012 07:45:48 +0200
Subject: [Dwarf-Discuss] DWARF on systems where memory is not byte
	addressable
Message-ID: <20120726054548.GH18124@calamari.ace.nl>

Hello all, I am wondering about how to deal with platforms with word
memories, by which I mean that the smallest addressable unit in memory
is (in our current case) 32 bits wide.  This means that at the C level, 

	sizeof(char) == sizeof(short) == sizeof(int) == 1,

so far so good.  However, we are having problems with gdb.  I am aware
that this may be entirely gdb specific but I do note that the standard
does not spend a lot of words on the issues that arise here, that's
why I bring this up here.

The standard does not seem to define anywhere how large a byte is
supposed to be.  Historically, older architectures used anything out
of 6, 7, 8 and 9 bits bytes which is why networking standards tend to
speak of octets instead.  DWARF seems to assume 8 bit bytes, hence the
LEB128 encoding, but it does not state so explicitly unless I
overlooked something.

A C oriented view might consider that sizeof(char) == sizeof(int), and
as C does not distinguish clearly between byte and char, take a byte
to be 32 bits wide.  But even that's not always the case as sometimes
we see word oriented platforms which still take the arithmetic size of
char to be 8 bits, requiring frequent sign- and zero-extension when
assigning to a char or short variable.

However, I assume that if the DWARF standard were explicit about the
size of a byte, it would define a byte to be 8 bits.

The problem we see with gdb hinges on the DW_AT_byte_size attribute of
a type descriptor.  Gdb uses it for at least two purposes:

	- to perform address arithmetic

	- to determine the bit size of values

If we set the DW_AT_byte_size of an integer to 1, gdb will do the
address arithmetic correctly, that is, look for int_array[1] at
address int_array + 1, not + 4, but if you ask for the value of an int
variable it will only display the lower 8 bits.

If we set the DW_AT_byte_size of int to 4, which indeed sounds
more consistent given the name _byte_size, gdb will extract the full
32 bits of the value but get the address arithmetic wrong as
int_array[1] now actually accesses int_array[4].

It seems to me that the proper way would be to fix gdb to take the
addressing size unit into account as general knowledge of the target
platform, but I can't believe we're the first to come across this.  I
wonder if anyone on this list has already faced similar issues and
what they did about it.

Best regards,

Joeri van Ruth

-- 
Joeri van Ruth, ACE Associated Compiler Experts
De Ruyterkade 113, 1011 AB Amsterdam, The Netherlands.
Tel: +31 20 6646416, Fax: +31 20 6750389,
mailto:joeri at ace.nl, http://www.ace.nl
___________________________________________________________________________
This e-mail and any files transmitted with it are confidential. Any tech-
nical information contained herein is supplied as-is, and no rights can
be derived therefrom. Unless you are the intended recipient, you should
not read, disclose, copy, or otherwise use the information in this message.
If you have received the message in error, please notify the sender by
reply e-mail immediately and delete the message and all copies thereof.





From mjw@redhat.com  Thu Jul 26 10:11:13 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Thu, 26 Jul 2012 12:11:13 +0200
Subject: [Dwarf-Discuss] DwarfExtensions
Message-ID: <1343297473.16205.9.camel@springer.wildebeest.org>

Hi,

For the elfutils project (https://fedorahosted.org/elfutils/), which
includes libdw a DWARF consumer library used by programs like perf,
systemtap and the dwarves tools, I wrote up a wiki page with all the
DWARF extensions known to the library:

https://fedorahosted.org/elfutils/wiki/DwarfExtensions

elfutils is mainly focused on supporting the GNU toolchain, so the list
is somewhat GNU specific, but does contain extensions from other
"vendors" adopted by GNU.

I tried to include links to all the descriptions that I could find,
which producer generates them and/or whether the extension has been
proposed for DWARF5. But there are still a lot of unknowns. Do others
have similar overviews for extensions DWARF producers generate and/or
consumers recognize? Or just links to descriptions of the extensions
currently listed as "unknown"?

Thanks,

Mark



From davea42@earthlink.net  Thu Jul 26 14:22:36 2012
From: davea42@earthlink.net (David Anderson)
Date: Thu, 26 Jul 2012 07:22:36 -0700
Subject: [Dwarf-Discuss] DwarfExtensions
In-Reply-To: <1343297473.16205.9.camel@springer.wildebeest.org>
References: <1343297473.16205.9.camel@springer.wildebeest.org>
Message-ID: <501152AC.8030302@earthlink.net>

On 07/26/2012 03:11 AM, Mark Wielaard wrote:
> Hi,
>
> For the elfutils project (https://fedorahosted.org/elfutils/), which
> includes libdw a DWARF consumer library used by programs like perf,
> systemtap and the dwarves tools, I wrote up a wiki page with all the
> DWARF extensions known to the library:
>
> https://fedorahosted.org/elfutils/wiki/DwarfExtensions
>

Some comments.

Some of the DW_AT_MIPS extensions were invented in the mid 1990's at SGI but 

were never emitted.  No SGI compiler emitted them that I am aware of
(I was in the compiler group 1988-2006 and responsible for libdwarf and 
for SGI debuggers
among other things).   These were given the designation MIPS (instead of 
SGI)
because we thought that was just a better thing to do.


DW_TAG_MIPS_loop
DW_AT_MIPS_loop_begin
DW_AT_MIPS_tail_loop_begin
DW_AT_MIPS_epilog_begin
DW_AT_MIPS_loop_unroll_factor
DW_AT_MIPS_software_pipeline_depth

are in the class of attributes that were never implemented at SGI/MIPS. 
So I doubt if anyone
ever emitted them.  The implied compiler optimizations were done at SGI 
in-period, but no
DWARF was emitted describing the optimizations.

The mips_extensions pdf (written by me at SGI
in-period and still distributed with libdwarf and dwarfdump)  which 
explains
what some of the original MIPS
extensions (only a couple of which were widely used)
meant. (I emailed Mark the pdf in separate email).

Corrections are welcome.

David Anderson

-- 
I told the doctor I broke my leg in two places. He told me to quit going to those places. -- Henny Youngman




From eager@eagercon.com  Thu Jul 26 15:37:36 2012
From: eager@eagercon.com (Michael Eager)
Date: Thu, 26 Jul 2012 08:37:36 -0700
Subject: [Dwarf-Discuss] DWARF on systems where memory is not byte
	addressable
In-Reply-To: <20120726054548.GH18124@calamari.ace.nl>
References: <20120726054548.GH18124@calamari.ace.nl>
Message-ID: <50116440.5030904@eagercon.com>

On 07/25/2012 10:45 PM, Joeri van Ruth wrote:
> Hello all, I am wondering about how to deal with platforms with word
> memories, by which I mean that the smallest addressable unit in memory
> is (in our current case) 32 bits wide.  This means that at the C level,
>
> 	sizeof(char) == sizeof(short) == sizeof(int) == 1,
>
> so far so good.  However, we are having problems with gdb.  I am aware
> that this may be entirely gdb specific but I do note that the standard
> does not spend a lot of words on the issues that arise here, that's
> why I bring this up here.
>
> The standard does not seem to define anywhere how large a byte is
> supposed to be.  Historically, older architectures used anything out
> of 6, 7, 8 and 9 bits bytes which is why networking standards tend to
> speak of octets instead.  DWARF seems to assume 8 bit bytes, hence the
> LEB128 encoding, but it does not state so explicitly unless I
> overlooked something.

DWARF does not make any assumptions that a byte on the architecture
being described is any particular size.  It does assume that data files
containing the DWARF debug data are read or written in 8-bit bytes.
LEB128 is a method for encoding arbitrary length integers into a
sequence of 8-bit bytes in the DWARF data.

> A C oriented view might consider that sizeof(char) == sizeof(int), and
> as C does not distinguish clearly between byte and char, take a byte
> to be 32 bits wide.  But even that's not always the case as sometimes
> we see word oriented platforms which still take the arithmetic size of
> char to be 8 bits, requiring frequent sign- and zero-extension when
> assigning to a char or short variable.

Your point isn't clear.  The C Standard doesn't describe bytes.  The
size of an an addressing unit doesn't have any direct relationship with
the size of data which can be accessed.  Many RISC architectures only
permit register-sized memory transfers, while the address unit is
8-bit bytes.  There are some word-addressed architectures which allow
memory reference to shorter data sizes.

Word-oriented platforms which have byte-addressable memory seems be a
self-contradiction.

> However, I assume that if the DWARF standard were explicit about the
> size of a byte, it would define a byte to be 8 bits.

There a relevant sections in the standard:

   2.21 Byte and Bit Sizes

   Many debugging information entries allow either a DW_AT_byte_size attribute
   or a DW_AT_bit_size attribute, whose integer constant value (see Section 2.19)
   specifies an amount of storage. The value of the DW_AT_byte_size attribute is
   interpreted in bytes and the value of the DW_AT_bit_size attribute is
   interpreted in bits.

My understanding is that DW_AT_byte_size is in address units (or storage units)
in the target architecture.

> The problem we see with gdb hinges on the DW_AT_byte_size attribute of
> a type descriptor.  Gdb uses it for at least two purposes:
>
> 	- to perform address arithmetic
>
> 	- to determine the bit size of values
>
> If we set the DW_AT_byte_size of an integer to 1, gdb will do the
> address arithmetic correctly, that is, look for int_array[1] at
> address int_array + 1, not + 4, but if you ask for the value of an int
> variable it will only display the lower 8 bits.
>
> If we set the DW_AT_byte_size of int to 4, which indeed sounds
> more consistent given the name _byte_size, gdb will extract the full
> 32 bits of the value but get the address arithmetic wrong as
> int_array[1] now actually accesses int_array[4].
>
> It seems to me that the proper way would be to fix gdb to take the
> addressing size unit into account as general knowledge of the target
> platform, but I can't believe we're the first to come across this.  I
> wonder if anyone on this list has already faced similar issues and
> what they did about it.

Word-addressed architectures are pretty uncommon and I would not be
surprised if gdb did not handle address calculations correctly.
Gdb has the definition TARGET_CHAR_BIT which defines the number of
bits in a char (aka byte) on the target architecture.  It may not
be taking this into account with address arithmetic or memory access.

The DWARF standard may not be as clear as might be desired with the
description of DW_AT_byte_size.  Feel free to submit a comment or
proposed change at http://dwarfstd.org/Comment.php.

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





From eager@eagercon.com  Thu Jul 26 15:42:04 2012
From: eager@eagercon.com (Michael Eager)
Date: Thu, 26 Jul 2012 08:42:04 -0700
Subject: [Dwarf-Discuss] DwarfExtensions
In-Reply-To: <1343297473.16205.9.camel@springer.wildebeest.org>
References: <1343297473.16205.9.camel@springer.wildebeest.org>
Message-ID: <5011654C.7020506@eagercon.com>

On 07/26/2012 03:11 AM, Mark Wielaard wrote:
> Hi,
>
> For the elfutils project (https://fedorahosted.org/elfutils/), which
> includes libdw a DWARF consumer library used by programs like perf,
> systemtap and the dwarves tools, I wrote up a wiki page with all the
> DWARF extensions known to the library:
>
> https://fedorahosted.org/elfutils/wiki/DwarfExtensions
>
> elfutils is mainly focused on supporting the GNU toolchain, so the list
> is somewhat GNU specific, but does contain extensions from other
> "vendors" adopted by GNU.
>
> I tried to include links to all the descriptions that I could find,
> which producer generates them and/or whether the extension has been
> proposed for DWARF5. But there are still a lot of unknowns. Do others
> have similar overviews for extensions DWARF producers generate and/or
> consumers recognize? Or just links to descriptions of the extensions
> currently listed as "unknown"?

Thanks.  This is very useful info.

With your permission, I'd like to add this (or an adaptation) to the
DWARF wiki:  http://wiki.dwarfstd.org/index.php?title=Main_Page

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





From chris.quenelle@oracle.com  Thu Jul 26 18:54:47 2012
From: chris.quenelle@oracle.com (Chris Quenelle)
Date: Thu, 26 Jul 2012 11:54:47 -0700
Subject: [Dwarf-Discuss] DWARF on systems where memory is not byte
	addressable
In-Reply-To: <20120726054548.GH18124@calamari.ace.nl>
References: <20120726054548.GH18124@calamari.ace.nl>
Message-ID: <3F23BB94-1810-4F1D-9DA0-8B254ECA9AD0@oracle.com>


I don't really work in this area anymore, but I can wave my
hands around with the best of them, so here's my two cents.

It sounds like you are asking this question:

Is it easier to teach gdb that a byte is 32-bits long, or is it
easier to teach gdb that pointers are always missing their bottom
two bits (which would always be zero anyway).
(I would suggest taking one of those two approaches consistently,
otherwise it will be very hard to figure out what's going on.)

If that's really what your question boils down to, then I would look
first to the gdb code and decide which approach is better in gdb,
and then decide what possible tweaks you might need to make
in gcc dwarf generation to support those changes.

It doesn't seem like a formal definition of "what a byte is"
is going to actually help make any specific software work.
So that might be a red herring.

--chris




On Wednesday July 25, at    10:45PM, Joeri van Ruth wrote:

> Hello all, I am wondering about how to deal with platforms with word
> memories, by which I mean that the smallest addressable unit in memory
> is (in our current case) 32 bits wide.  This means that at the C level, 
> 
> 	sizeof(char) == sizeof(short) == sizeof(int) == 1,
> 
> so far so good.  However, we are having problems with gdb.  I am aware
> that this may be entirely gdb specific but I do note that the standard
> does not spend a lot of words on the issues that arise here, that's
> why I bring this up here.
> 
> The standard does not seem to define anywhere how large a byte is
> supposed to be.  Historically, older architectures used anything out
> of 6, 7, 8 and 9 bits bytes which is why networking standards tend to
> speak of octets instead.  DWARF seems to assume 8 bit bytes, hence the
> LEB128 encoding, but it does not state so explicitly unless I
> overlooked something.
> 
> A C oriented view might consider that sizeof(char) == sizeof(int), and
> as C does not distinguish clearly between byte and char, take a byte
> to be 32 bits wide.  But even that's not always the case as sometimes
> we see word oriented platforms which still take the arithmetic size of
> char to be 8 bits, requiring frequent sign- and zero-extension when
> assigning to a char or short variable.
> 
> However, I assume that if the DWARF standard were explicit about the
> size of a byte, it would define a byte to be 8 bits.
> 
> The problem we see with gdb hinges on the DW_AT_byte_size attribute of
> a type descriptor.  Gdb uses it for at least two purposes:
> 
> 	- to perform address arithmetic
> 
> 	- to determine the bit size of values
> 
> If we set the DW_AT_byte_size of an integer to 1, gdb will do the
> address arithmetic correctly, that is, look for int_array[1] at
> address int_array + 1, not + 4, but if you ask for the value of an int
> variable it will only display the lower 8 bits.
> 
> If we set the DW_AT_byte_size of int to 4, which indeed sounds
> more consistent given the name _byte_size, gdb will extract the full
> 32 bits of the value but get the address arithmetic wrong as
> int_array[1] now actually accesses int_array[4].
> 
> It seems to me that the proper way would be to fix gdb to take the
> addressing size unit into account as general knowledge of the target
> platform, but I can't believe we're the first to come across this.  I
> wonder if anyone on this list has already faced similar issues and
> what they did about it.
> 
> Best regards,
> 
> Joeri van Ruth
> 
> -- 
> Joeri van Ruth, ACE Associated Compiler Experts
> De Ruyterkade 113, 1011 AB Amsterdam, The Netherlands.
> Tel: +31 20 6646416, Fax: +31 20 6750389,
> mailto:joeri at ace.nl, http://www.ace.nl
> ___________________________________________________________________________
> This e-mail and any files transmitted with it are confidential. Any tech-
> nical information contained herein is supplied as-is, and no rights can
> be derived therefrom. Unless you are the intended recipient, you should
> not read, disclose, copy, or otherwise use the information in this message.
> If you have received the message in error, please notify the sender by
> reply e-mail immediately and delete the message and all copies thereof.
> 
> 
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org




From Paul.Robinson@am.sony.com  Thu Jul 26 19:29:35 2012
From: Paul.Robinson@am.sony.com (Robinson, Paul)
Date: Thu, 26 Jul 2012 19:29:35 +0000
Subject: [Dwarf-Discuss] DWARF on systems where memory is not
	byte	addressable
In-Reply-To: <50116440.5030904@eagercon.com>
References: <20120726054548.GH18124@calamari.ace.nl>,
	<50116440.5030904@eagercon.com>
Message-ID: <380DDC5801D2BC41AB95DF407A939E350D8D4295@USCULXMSG03.am.sony.com>



________________________________________
From: dwarf-discuss-bounces at lists.dwarfstd.org [dwarf-discuss-bounces at lists.dwarfstd.org] on behalf of Michael Eager [eager@eagercon.com]
Sent: Thursday, July 26, 2012 8:37 AM
To: Joeri van Ruth
Cc: dwarf-discuss at lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] DWARF on systems where memory is not byte  addressable

Joeri van Ruth wrote:
> Hello all, I am wondering about how to deal with platforms with word
> memories, by which I mean that the smallest addressable unit in memory
> is (in our current case) 32 bits wide.  This means that at the C level,
>
>       sizeof(char) == sizeof(short) == sizeof(int) == 1,
>
> so far so good.  However, we are having problems with gdb.  I am aware
> that this may be entirely gdb specific but I do note that the standard
> does not spend a lot of words on the issues that arise here, that's
> why I bring this up here.
>
> The standard does not seem to define anywhere how large a byte is
> supposed to be.  Historically, older architectures used anything out
> of 6, 7, 8 and 9 bits bytes which is why networking standards tend to
> speak of octets instead.  DWARF seems to assume 8 bit bytes, hence the
> LEB128 encoding, but it does not state so explicitly unless I
> overlooked something.
>
> A C oriented view might consider that sizeof(char) == sizeof(int), and
> as C does not distinguish clearly between byte and char, take a byte
> to be 32 bits wide.  But even that's not always the case as sometimes
> we see word oriented platforms which still take the arithmetic size of
> char to be 8 bits, requiring frequent sign- and zero-extension when
> assigning to a char or short variable.

Michael Eager wrote:
>Word-oriented platforms which have byte-addressable memory seems be a
>self-contradiction.

The PDP-10 (my first machine) was a 36-bit word-addressable machine.
It had a "byte pointer" format that could specify an arbitrary byte within a
word. So, there was a hardware-defined bit pattern to specify any given
byte in memory, and instructions that could load and store just that byte.
Nobody ever described the PDP-10 as byte-addressable, but you could
make a pedantic argument for it.

I remember hearing about a C compiler for the PDP-10 that handled
"char" as bytes addressed with byte pointers, and pointer arithmetic
understood whether it was manipulating a byte pointer or a word address.
Typical practice of that era would have been five 7-bit chars per word.
I don't remember how it handled sizeof().

Making this trip down memory lane relevant to the topic at hand:
This predates DWARF, of course, so sadly I do not have any guidance
about how to use DWARF on a word-addressable machine.
If there's an existing body of software that handles text, on this machine,
the typical way that text is managed (1 char per word? seems
wasteful; 4 chars per word?) that might guide some of your choices
about how to think about "char".

--paulr



From eager@eagercon.com  Thu Jul 26 20:02:12 2012
From: eager@eagercon.com (Michael Eager)
Date: Thu, 26 Jul 2012 13:02:12 -0700
Subject: [Dwarf-Discuss] DWARF on systems where memory is not byte
	addressable
In-Reply-To: <380DDC5801D2BC41AB95DF407A939E350D8D4295@USCULXMSG03.am.sony.com>
References: <20120726054548.GH18124@calamari.ace.nl>,
	<50116440.5030904@eagercon.com>
	<380DDC5801D2BC41AB95DF407A939E350D8D4295@USCULXMSG03.am.sony.com>
Message-ID: <5011A244.50708@eagercon.com>

On 07/26/2012 12:29 PM, Robinson, Paul wrote:
>

> Michael Eager wrote:
>> Word-oriented platforms which have byte-addressable memory seems be a
>> self-contradiction.
>
> The PDP-10 (my first machine) was a 36-bit word-addressable machine.
> It had a "byte pointer" format that could specify an arbitrary byte within a
> word. So, there was a hardware-defined bit pattern to specify any given
> byte in memory, and instructions that could load and store just that byte.
> Nobody ever described the PDP-10 as byte-addressable, but you could
> make a pedantic argument for it.

So were several Burroughs machines.  None had byte addressable memory.
Each that I'm acquainted with (and many other architectures) have
instructions which will extract a sub-word value from an addressable unit.

DWARF describes data in terms of memory addressable units.  Let's not
let contrived arguments confuse the issue.

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





From tromey@redhat.com  Thu Jul 26 20:57:01 2012
From: tromey@redhat.com (Tom Tromey)
Date: Thu, 26 Jul 2012 14:57:01 -0600
Subject: [Dwarf-Discuss] DWARF on systems where memory is not byte
	addressable
In-Reply-To: <50116440.5030904@eagercon.com> (Michael Eager's message of "Thu, 
	26 Jul 2012 08:37:36 -0700")
References: <20120726054548.GH18124@calamari.ace.nl>
	<50116440.5030904@eagercon.com>
Message-ID: <87zk6mckbm.fsf@fleche.redhat.com>

>>>>> "Michael" == Michael Eager <eager at eagercon.com> writes:

Michael> Gdb has the definition TARGET_CHAR_BIT which defines the number of
Michael> bits in a char (aka byte) on the target architecture.  It may not
Michael> be taking this into account with address arithmetic or memory access.

My impression is that TARGET_CHAR_BIT was one of those projects that was
started in gdb and never really finished.  There are certainly many
places remaining that assume 8 bit bytes.

Tom



From mjw@redhat.com  Thu Jul 26 21:04:09 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Thu, 26 Jul 2012 23:04:09 +0200
Subject: [Dwarf-Discuss] DwarfExtensions
In-Reply-To: <5011654C.7020506@eagercon.com>
References: <1343297473.16205.9.camel@springer.wildebeest.org>
	<5011654C.7020506@eagercon.com>
Message-ID: <20120726210409.GB28031@toonder.wildebeest.org>

On Thu, Jul 26, 2012 at 08:42:04AM -0700, Michael Eager wrote:
> >For the elfutils project (https://fedorahosted.org/elfutils/), which
> >includes libdw a DWARF consumer library used by programs like perf,
> >systemtap and the dwarves tools, I wrote up a wiki page with all the
> >DWARF extensions known to the library:
> >
> >https://fedorahosted.org/elfutils/wiki/DwarfExtensions
> [...]
> Thanks.  This is very useful info.
> 
> With your permission, I'd like to add this (or an adaptation) to the
> DWARF wiki:  http://wiki.dwarfstd.org/index.php?title=Main_Page

Sure. It would be nice to have a somewhat canonical place that has
pointers to descriptions of vendor extensions. I updated the version
on the elfutils wiki a bit using the information that David Anderson
provided.

Thanks,

Mark



From Paul.Robinson@am.sony.com  Thu Jul 26 21:25:23 2012
From: Paul.Robinson@am.sony.com (Robinson, Paul)
Date: Thu, 26 Jul 2012 21:25:23 +0000
Subject: [Dwarf-Discuss] DWARF on systems where memory is not
	byte	addressable
In-Reply-To: <20120726054548.GH18124@calamari.ace.nl>
References: <20120726054548.GH18124@calamari.ace.nl>
Message-ID: <380DDC5801D2BC41AB95DF407A939E350D8D49B6@USCULXMSG03.am.sony.com>

Joeri van Ruth wrote:
> However, I assume that if the DWARF standard were explicit about the
> size of a byte, it would define a byte to be 8 bits.

As Michael said, if DWARF were to say anything more than it does, it 
should be in terms of memory-addressable units; although finding specific 
wording that is unambiguous for all the funky architectures in the world
would be something of a trick.

> If we set the DW_AT_byte_size of an integer to 1, gdb will do the
> address arithmetic correctly, that is, look for int_array[1] at
> address int_array + 1, not + 4, but if you ask for the value of an int
> variable it will only display the lower 8 bits.

Truncating the value is a GDB bug.  You could try specifying bit_size=32
as well as byte_size=1, and see what happens. No promises.

Do you store one char per word, or multiple chars per word?
If it's one char per word, then bit_size=8 should be reasonable.
If it's multiple chars per word, then "char*" has to be more than a
simple address, and you'll have to define a new address class
(DW_ADDR_xxxxx) and teach the debugger how to interpret
values with that address class.

--paulr



From arunks.linux@gmail.com  Fri Jul 27 09:44:48 2012
From: arunks.linux@gmail.com (Arun KS)
Date: Fri, 27 Jul 2012 15:14:48 +0530
Subject: [Dwarf-Discuss] Decoding DW_FORM_block1
Message-ID: <CAKZGPAOvdUWkpUXfRTp0yQc0-PrjJo5F7nw4ZYO2MLD=pTGtfA@mail.gmail.com>

Hello Guys,

I m not able to decode form DW_FORM_block1. I am able to read till
attr data_member_location(marked with <<<<<<<<< below.).
The form is comming as DW_FORM_block1. So I went and read debug_info,
which gave me 0x2. So this means
length is 2 and i have to read two more bytes. The next two bytes in
.debug_info are 0x23 and 0x00.

What this values represent(0x23 an 0x00)?
>From where will I get  "[   0] plus_uconst 0" printed by "eu-readelf
-winfo a.out"

Please help.

Here is the output given by the eu-readelf -winfo a.out,

DWARF section [29] '.debug_info' at offset 0x781:
 [Offset]
 Compilation unit at offset 0:
 Version: 2, Abbreviation section offset: 0, Address size: 4, Offset size: 4
 [     b]  compile_unit
           producer             "GNU C 4.3.3"
           language             ISO C89 (1)
           name                 "1.c"
           comp_dir             "/home/arun/Desktop/test"
           low_pc               0x000083f8 <main>
           high_pc              0x00008410 <test_func>
           stmt_list            0
 [    25]    structure_type
             name                 "vinayak"
             byte_size            8
             decl_file            2
             decl_line            1
             sibling              [    4e]
 [    31]      member
               name                 "vinayak_i"
               decl_file            2
               decl_line            2
               type                 [    4e]
               data_member_location                 [   0] plus_uconst
0                       <<<<<<<<<<<<<<<<<<<<<<
 [    3f]      member
               name                 "vinayak_u"
               decl_file            2
               decl_line            3
               type                 [    55]
               data_member_location                 [   0] plus_uconst 4
=================================================
Here is the output from eu-readelf -wabbrev a.out

DWARF section [30] '.debug_abbrev' at offset 0x978:
 [ Code]

Abbreviation section at offset 0:
 [    1] offset: 0, children: yes, tag: compile_unit
          attr: producer, form: strp, offset: 0
          attr: language, form: data1, offset: 0x2
          attr: name, form: string, offset: 0x4
          attr: comp_dir, form: strp, offset: 0x6
          attr: low_pc, form: addr, offset: 0x8
          attr: high_pc, form: addr, offset: 0xa
          attr: stmt_list, form: data4, offset: 0xc
 [    2] offset: 19, children: yes, tag: structure_type
          attr: name, form: strp, offset: 0x13
          attr: byte_size, form: data1, offset: 0x15
          attr: decl_file, form: data1, offset: 0x17
          attr: decl_line, form: data1, offset: 0x19
          attr: sibling, form: ref4, offset: 0x1b
 [    3] offset: 34, children: no, tag: member
          attr: name, form: strp, offset: 0x22
          attr: decl_file, form: data1, offset: 0x24
          attr: decl_line, form: data1, offset: 0x26
          attr: type, form: ref4, offset: 0x28
          attr: data_member_location, form: block1, offset: 0x2a
 [    4] offset: 49, children: no, tag: base_type
          attr: byte_size, form: data1, offset: 0x31
          attr: encoding, form: data1, offset: 0x33


Thanks,
Arun



From mjw@redhat.com  Fri Jul 27 13:01:36 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Fri, 27 Jul 2012 15:01:36 +0200
Subject: [Dwarf-Discuss] Decoding DW_FORM_block1
In-Reply-To: <CAKZGPAOvdUWkpUXfRTp0yQc0-PrjJo5F7nw4ZYO2MLD=pTGtfA@mail.gmail.com>
References: <CAKZGPAOvdUWkpUXfRTp0yQc0-PrjJo5F7nw4ZYO2MLD=pTGtfA@mail.gmail.com>
Message-ID: <1343394096.16205.28.camel@springer.wildebeest.org>

On Fri, 2012-07-27 at 15:14 +0530, Arun KS wrote:
> Hello Guys,
> 
> I m not able to decode form DW_FORM_block1. I am able to read till
> attr data_member_location(marked with <<<<<<<<< below.).
> The form is comming as DW_FORM_block1. So I went and read debug_info,
> which gave me 0x2. So this means
> length is 2 and i have to read two more bytes. The next two bytes in
> .debug_info are 0x23 and 0x00.
> 
> What this values represent(0x23 an 0x00)?
> From where will I get  "[   0] plus_uconst 0" printed by "eu-readelf
> -winfo a.out"

So that is like eu-readelf tells you a block containing "0x23 0x00" aka
"DW_OP_plus_uconst 0x0", which together with the address of the
structure begin address on the dwarf stack, forms a location description
of the member. Note that newer instead of a block of opcodes, this can
also be expressed as a constant form by the producer, which would be
slightly more efficient. See "5.5.6 Data Member Entries" in the DWARF4
spec.

Cheers,

Mark



From arunks.linux@gmail.com  Fri Jul 27 14:02:08 2012
From: arunks.linux@gmail.com (Arun KS)
Date: Fri, 27 Jul 2012 19:32:08 +0530
Subject: [Dwarf-Discuss] Decoding DW_FORM_block1
In-Reply-To: <1343394096.16205.28.camel@springer.wildebeest.org>
References: <CAKZGPAOvdUWkpUXfRTp0yQc0-PrjJo5F7nw4ZYO2MLD=pTGtfA@mail.gmail.com>
	<1343394096.16205.28.camel@springer.wildebeest.org>
Message-ID: <CAKZGPAMgDYAY1Vy0dnMvY_hORXN3YvHrRN+kC8XD14mWXveJdA@mail.gmail.com>

Hi Mark,

On Fri, Jul 27, 2012 at 6:31 PM, Mark Wielaard <mjw at redhat.com> wrote:
> On Fri, 2012-07-27 at 15:14 +0530, Arun KS wrote:
>> Hello Guys,
>>
>> I m not able to decode form DW_FORM_block1. I am able to read till
>> attr data_member_location(marked with <<<<<<<<< below.).
>> The form is comming as DW_FORM_block1. So I went and read debug_info,
>> which gave me 0x2. So this means
>> length is 2 and i have to read two more bytes. The next two bytes in
>> .debug_info are 0x23 and 0x00.
>>
>> What this values represent(0x23 an 0x00)?
>> From where will I get  "[   0] plus_uconst 0" printed by "eu-readelf
>> -winfo a.out"
>
> So that is like eu-readelf tells you a block containing "0x23 0x00" aka
> "DW_OP_plus_uconst 0x0", which together with the address of the
> structure begin address on the dwarf stack, forms a location description
> of the member. Note that newer instead of a block of opcodes, this can
> also be expressed as a constant form by the producer, which would be
> slightly more efficient. See "5.5.6 Data Member Entries" in the DWARF4
> spec.
Thanks for the reply.
I m writting a program which decodes the DWARF sections in vmlinux.
But facing some issues.

             decl_file            2
             decl_line            1
             sibling              [    4e]
 [    31]      member
               name                 "vinayak_i"
               decl_file            2
               decl_line            2
               type                 [    4e]
               data_member_location                 [   0] plus_uconst 0
>>>>>>>>>>>>>>>>
<Arun>Things were fine till this point,

 [    3f]      member
               name                 "vinayak_u"
               decl_file            2
               decl_line            3
               type                 [    55]
               data_member_location                 [   0] plus_uconst 4
 [    4e]    base_type
             byte_size            4
             encoding             signed (5)
             name                 "int"

.debug_abbrev follows:

 [    2] offset: 19, children: yes, tag: structure_type
          attr: name, form: strp, offset: 0x13
          attr: byte_size, form: data1, offset: 0x15
          attr: decl_file, form: data1, offset: 0x17
          attr: decl_line, form: data1, offset: 0x19
          attr: sibling, form: ref4, offset: 0x1b
 [    3] offset: 34, children: no, tag: member
          attr: name, form: strp, offset: 0x22
          attr: decl_file, form: data1, offset: 0x24
          attr: decl_line, form: data1, offset: 0x26
          attr: type, form: ref4, offset: 0x28
          attr: data_member_location, form: block1, offset: 0x2a

>>>>>>Why no entry in .debug_abbrev for second member named "vinayak_u"?
.debug_abbrev is directly going to base_type

 [    4] offset: 49, children: no, tag: base_type
          attr: byte_size, form: data1, offset: 0x31
          attr: encoding, form: data1, offset: 0x33

Thanks,
Arun


>
> Cheers,
>
> Mark



From mjw@redhat.com  Fri Jul 27 14:50:14 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Fri, 27 Jul 2012 16:50:14 +0200
Subject: [Dwarf-Discuss] Decoding DW_FORM_block1
In-Reply-To: <CAKZGPAMgDYAY1Vy0dnMvY_hORXN3YvHrRN+kC8XD14mWXveJdA@mail.gmail.com>
References: <CAKZGPAOvdUWkpUXfRTp0yQc0-PrjJo5F7nw4ZYO2MLD=pTGtfA@mail.gmail.com>
	<1343394096.16205.28.camel@springer.wildebeest.org>
	<CAKZGPAMgDYAY1Vy0dnMvY_hORXN3YvHrRN+kC8XD14mWXveJdA@mail.gmail.com>
Message-ID: <1343400614.16205.34.camel@springer.wildebeest.org>

On Fri, 2012-07-27 at 19:32 +0530, Arun KS wrote:
> On Fri, Jul 27, 2012 at 6:31 PM, Mark Wielaard <mjw at redhat.com> wrote:
> > On Fri, 2012-07-27 at 15:14 +0530, Arun KS wrote:
>  [    31]      member
>                name                 "vinayak_i"
>                decl_file            2
>                decl_line            2
>                type                 [    4e]
>                data_member_location                 [   0] plus_uconst 0
> >>>>>>>>>>>>>>>>
> <Arun>Things were fine till this point,
> 
>  [    3f]      member
>                name                 "vinayak_u"
>                decl_file            2
>                decl_line            3
>                type                 [    55]
>                data_member_location                 [   0] plus_uconst 4

Note that eu-readelf --debug-dump=info doesn't show you the abbrev
numbers. Most likely is that both members use the same abbrev number.

> .debug_abbrev follows:
> 
>  [    2] offset: 19, children: yes, tag: structure_type
>           attr: name, form: strp, offset: 0x13
>           attr: byte_size, form: data1, offset: 0x15
>           attr: decl_file, form: data1, offset: 0x17
>           attr: decl_line, form: data1, offset: 0x19
>           attr: sibling, form: ref4, offset: 0x1b
>  [    3] offset: 34, children: no, tag: member
>           attr: name, form: strp, offset: 0x22
>           attr: decl_file, form: data1, offset: 0x24
>           attr: decl_line, form: data1, offset: 0x26
>           attr: type, form: ref4, offset: 0x28
>           attr: data_member_location, form: block1, offset: 0x2a
> 
> >>>>>>Why no entry in .debug_abbrev for second member named "vinayak_u"?
> .debug_abbrev is directly going to base_type

The DIE tree in the .debug_info points to the abbrevs that describe
them. Most likely both point to [3] here. See "7.5.2 Debugging
Information Entry" in the DWARF4 spec.

You might want to use a library like libdw from elfutils or libdwarf to
parse DWARF if a tool like eu-readelf doesn't give you the information
you need.

Cheers,

Mark



From arunks.linux@gmail.com  Mon Jul 30 13:07:33 2012
From: arunks.linux@gmail.com (Arun KS)
Date: Mon, 30 Jul 2012 18:37:33 +0530
Subject: [Dwarf-Discuss] Decoding DW_FORM_block1
In-Reply-To: <1343400614.16205.34.camel@springer.wildebeest.org>
References: <CAKZGPAOvdUWkpUXfRTp0yQc0-PrjJo5F7nw4ZYO2MLD=pTGtfA@mail.gmail.com>
	<1343394096.16205.28.camel@springer.wildebeest.org>
	<CAKZGPAMgDYAY1Vy0dnMvY_hORXN3YvHrRN+kC8XD14mWXveJdA@mail.gmail.com>
	<1343400614.16205.34.camel@springer.wildebeest.org>
Message-ID: <CAKZGPAMgMydZetYyJs9mbsq6Fnc6_NDAsubND5-eRNzfrzz6OQ@mail.gmail.com>

Hi Mark,

On Fri, Jul 27, 2012 at 8:20 PM, Mark Wielaard <mjw at redhat.com> wrote:
> On Fri, 2012-07-27 at 19:32 +0530, Arun KS wrote:
>> On Fri, Jul 27, 2012 at 6:31 PM, Mark Wielaard <mjw at redhat.com> wrote:
>> > On Fri, 2012-07-27 at 15:14 +0530, Arun KS wrote:
>>  [    31]      member
>>                name                 "vinayak_i"
>>                decl_file            2
>>                decl_line            2
>>                type                 [    4e]
>>                data_member_location                 [   0] plus_uconst 0
>> >>>>>>>>>>>>>>>>
>> <Arun>Things were fine till this point,
>>
>>  [    3f]      member
>>                name                 "vinayak_u"
>>                decl_file            2
>>                decl_line            3
>>                type                 [    55]
>>                data_member_location                 [   0] plus_uconst 4
>
> Note that eu-readelf --debug-dump=info doesn't show you the abbrev
> numbers. Most likely is that both members use the same abbrev number.
>
>> .debug_abbrev follows:
>>
>>  [    2] offset: 19, children: yes, tag: structure_type
>>           attr: name, form: strp, offset: 0x13
>>           attr: byte_size, form: data1, offset: 0x15
>>           attr: decl_file, form: data1, offset: 0x17
>>           attr: decl_line, form: data1, offset: 0x19
>>           attr: sibling, form: ref4, offset: 0x1b
>>  [    3] offset: 34, children: no, tag: member
>>           attr: name, form: strp, offset: 0x22
>>           attr: decl_file, form: data1, offset: 0x24
>>           attr: decl_line, form: data1, offset: 0x26
>>           attr: type, form: ref4, offset: 0x28
>>           attr: data_member_location, form: block1, offset: 0x2a
>>
>> >>>>>>Why no entry in .debug_abbrev for second member named "vinayak_u"?
>> .debug_abbrev is directly going to base_type
>
> The DIE tree in the .debug_info points to the abbrevs that describe
> them. Most likely both point to [3] here. See "7.5.2 Debugging
> Information Entry" in the DWARF4 spec.

Thanks for pointing this out. I was blocked here.
Thank you very much.

Arun

>
> You might want to use a library like libdw from elfutils or libdwarf to
> parse DWARF if a tool like eu-readelf doesn't give you the information
> you need.
>
> Cheers,
>
> Mark



