From eliben@gmail.com  Sat Dec 10 11:59:29 2011
From: eliben@gmail.com (Eli Bendersky)
Date: Sat, 10 Dec 2011 13:59:29 +0200
Subject: [Dwarf-Discuss] target address dependency of the FDE header in
	DWARF CFI
Message-ID: <CAF-Rda9cw96xD6Vk5j8wpEU1szateuMm06hG6thR6sjVrVKCKQ@mail.gmail.com>

Hello,

My question refers to seciton "6.4 - Call Frame Information" of v3 of the
DWARF standard.
This section states that the .debug_frame section is independent of any
debug info sections.

At the same time, the FDE header has fields "initial_location" and
"address_range", both of type "target address", which is not determined
globally in the DWARF file, but rather per CU (in the address_size field of
the CU header).

How am I supposed to determine the target size from the .debug_frame
section alone, without looking at CUs?

Thanks in advance
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111210/f165175e/attachment.htm>


From jan.kratochvil@redhat.com  Sat Dec 10 12:02:48 2011
From: jan.kratochvil@redhat.com (Jan Kratochvil)
Date: Sat, 10 Dec 2011 13:02:48 +0100
Subject: [Dwarf-Discuss] target address dependency of the FDE header in
 DWARF CFI
In-Reply-To: <CAF-Rda9cw96xD6Vk5j8wpEU1szateuMm06hG6thR6sjVrVKCKQ@mail.gmail.com>
References: <CAF-Rda9cw96xD6Vk5j8wpEU1szateuMm06hG6thR6sjVrVKCKQ@mail.gmail.com>
Message-ID: <20111210120248.GA27591@host2.jankratochvil.net>

On Sat, 10 Dec 2011 12:59:29 +0100, Eli Bendersky wrote:
> How am I supposed to determine the target size from the .debug_frame
> section alone, without looking at CUs?

I believe this is already filed as:
	http://dwarfstd.org/ShowIssue.php?issue=110926.1&type=open

Issues are listed at:
	http://dwarfstd.org/Issues.php


Regards,
Jan



From eliben@gmail.com  Sat Dec 10 12:09:32 2011
From: eliben@gmail.com (Eli Bendersky)
Date: Sat, 10 Dec 2011 14:09:32 +0200
Subject: [Dwarf-Discuss] target address dependency of the FDE header in
 DWARF CFI
In-Reply-To: <20111210120248.GA27591@host2.jankratochvil.net>
References: <CAF-Rda9cw96xD6Vk5j8wpEU1szateuMm06hG6thR6sjVrVKCKQ@mail.gmail.com>
	<20111210120248.GA27591@host2.jankratochvil.net>
Message-ID: <CAF-Rda94ngaEcm6Dw28jmYM7BTWMRQ+qqJdPkKFAx54YthYesA@mail.gmail.com>

On Sat, Dec 10, 2011 at 14:02, Jan Kratochvil <jan.kratochvil at redhat.com>wrote:

> On Sat, 10 Dec 2011 12:59:29 +0100, Eli Bendersky wrote:
> > How am I supposed to determine the target size from the .debug_frame
> > section alone, without looking at CUs?
>
> I believe this is already filed as:
>        http://dwarfstd.org/ShowIssue.php?issue=110926.1&type=open
>
> Issues are listed at:
>        http://dwarfstd.org/Issues.php
>

Jan, it appears that in DWARFv4 a field was added with "address size",
which at least makes sense (except the clarification you pointed to).

But in DWARFv3 there's no such field, so where would I expect to find this
information in a file written with DWARFv3 info?

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


From jan.kratochvil@redhat.com  Sat Dec 10 12:26:41 2011
From: jan.kratochvil@redhat.com (Jan Kratochvil)
Date: Sat, 10 Dec 2011 13:26:41 +0100
Subject: [Dwarf-Discuss] target address dependency of the FDE header in
 DWARF CFI
In-Reply-To: <CAF-Rda94ngaEcm6Dw28jmYM7BTWMRQ+qqJdPkKFAx54YthYesA@mail.gmail.com>
References: <CAF-Rda9cw96xD6Vk5j8wpEU1szateuMm06hG6thR6sjVrVKCKQ@mail.gmail.com>
	<20111210120248.GA27591@host2.jankratochvil.net>
	<CAF-Rda94ngaEcm6Dw28jmYM7BTWMRQ+qqJdPkKFAx54YthYesA@mail.gmail.com>
Message-ID: <20111210122640.GA28214@host2.jankratochvil.net>

On Sat, 10 Dec 2011 13:09:32 +0100, Eli Bendersky wrote:
> But in DWARFv3 there's no such field, so where would I expect to find this
> information in a file written with DWARFv3 info?

GDB follows the architecture of that FDE, which is taken from the architecture
of the file (decode_frame_entry_1).

gdb/gdbarch.sh:
# dwarf2_addr_size is not used for .eh_frame FDEs, which are generally
# defined using the target's pointer size so far.
#
# Note that dwarf2_addr_size only needs to be redefined by a target if the
# GCC back-end defines a DWARF2_ADDR_SIZE other than the target pointer size,
# and if Dwarf versions < 4 need to be supported.

And it really defaults to: gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT

Only gdb/xstormy16-tdep.c uses set_gdbarch_dwarf2_addr_size to change it.

>From the DWARF point of view it is fixed in v4.


Regards,
Jan



From eliben@gmail.com  Sat Dec 10 13:16:52 2011
From: eliben@gmail.com (Eli Bendersky)
Date: Sat, 10 Dec 2011 15:16:52 +0200
Subject: [Dwarf-Discuss] target address dependency of the FDE header in
 DWARF CFI
In-Reply-To: <20111210122640.GA28214@host2.jankratochvil.net>
References: <CAF-Rda9cw96xD6Vk5j8wpEU1szateuMm06hG6thR6sjVrVKCKQ@mail.gmail.com>
	<20111210120248.GA27591@host2.jankratochvil.net>
	<CAF-Rda94ngaEcm6Dw28jmYM7BTWMRQ+qqJdPkKFAx54YthYesA@mail.gmail.com>
	<20111210122640.GA28214@host2.jankratochvil.net>
Message-ID: <CAF-Rda8kMg5d=VqTZBB2-yvWze_oejm1nq8Ss-E=PYEsNZZzww@mail.gmail.com>

On Sat, Dec 10, 2011 at 14:26, Jan Kratochvil <jan.kratochvil at redhat.com>wrote:

> On Sat, 10 Dec 2011 13:09:32 +0100, Eli Bendersky wrote:
> > But in DWARFv3 there's no such field, so where would I expect to find
> this
> > information in a file written with DWARFv3 info?
>
> GDB follows the architecture of that FDE, which is taken from the
> architecture
> of the file (decode_frame_entry_1).
>
> gdb/gdbarch.sh:
> # dwarf2_addr_size is not used for .eh_frame FDEs, which are generally
> # defined using the target's pointer size so far.
> #
> # Note that dwarf2_addr_size only needs to be redefined by a target if the
> # GCC back-end defines a DWARF2_ADDR_SIZE other than the target pointer
> size,
> # and if Dwarf versions < 4 need to be supported.
>
> And it really defaults to: gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT
>
> Only gdb/xstormy16-tdep.c uses set_gdbarch_dwarf2_addr_size to change it.
>
>
The problem is GDB is that it can cheat - it *knows* the pointer size of
the target architecture, of course, since it has to run it!

But what about a parser library, decoupled from actual execution? I looked
at the code of libdwarf and after some digging it appears that it uses the
EI_CLASS of the enclosing ELF object. If it's ELFCLASS64, it assumes a
8-byte target address size, otherwise 4 bytes.

I wonder if this is indeed the right way to go. I learned that the DWARF
format is quite distinct from target address size. That is, CUs with 8-byte
address size can appear in DWARF32 sections. But perhaps the ELF class is
more telling.


> From the DWARF point of view it is fixed in v4.
>

Indeed.

Thanks,
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111210/7fc94e3c/attachment.htm>


From davea42@earthlink.net  Sat Dec 10 16:40:43 2011
From: davea42@earthlink.net (David Anderson)
Date: Sat, 10 Dec 2011 08:40:43 -0800
Subject: [Dwarf-Discuss] target address dependency of the FDE header in
 DWARF CFI
In-Reply-To: <CAF-Rda8kMg5d=VqTZBB2-yvWze_oejm1nq8Ss-E=PYEsNZZzww@mail.gmail.com>
References: <CAF-Rda9cw96xD6Vk5j8wpEU1szateuMm06hG6thR6sjVrVKCKQ@mail.gmail.com>
	<20111210120248.GA27591@host2.jankratochvil.net>
	<CAF-Rda94ngaEcm6Dw28jmYM7BTWMRQ+qqJdPkKFAx54YthYesA@mail.gmail.com>
	<20111210122640.GA28214@host2.jankratochvil.net>
	<CAF-Rda8kMg5d=VqTZBB2-yvWze_oejm1nq8Ss-E=PYEsNZZzww@mail.gmail.com>
Message-ID: <4EE38B8B.4030305@earthlink.net>

On 12/10/2011 05:16 AM, Eli Bendersky wrote:
>
> But what about a parser library, decoupled from actual execution? I 
> looked at the code of libdwarf and after some digging it appears that 
> it uses the EI_CLASS of the enclosing ELF object. If it's ELFCLASS64, 
> it assumes a 8-byte target address size, otherwise 4 bytes.
>
> I wonder if this is indeed the right way to go. I learned that the 
> DWARF format is quite distinct from target address size. That is, CUs 
> with 8-byte address size can appear in DWARF32 sections. But perhaps 
> the ELF class is more telling.

The code you looked at in libdwarf is the default address size, the best 
guess available before
any CUs are read.    When a CU is read from .debug_info (assuming there 
is a .debug_info...)
the address size from the CU is picked up and replaces the default (for 
that CU only).
The CU specific address_size is used for that CU's  CIE/FDE set.  See 
de_pointer_size, cc_address_size
(sorry for the naming disconnect, I should make that more regular), and 
ci_address_size in libdwarf.

When a DWARF4 .debug_frame is read and there is no CU-specific 
address_size known the
address size from .debug_frame is used.

I happen to have a test object with .debug_frame and no .debug_info (and 
the Elf default address_size
does *not* match the address_size of the .debug_frame!) so I added code 
so the libdwarf caller
can set the address_size ....  of course the only way to know to make 
that call is via a human
realizing the situation.     But at least that made it possible that a 
determined human could use
dwarfdump/libdwarf on an object file like the one I mention here.

If you notice bugs/infelicities/omissions in libdwarf or dwarfdump, 
please do let me know. Thanks.
I just noticed I failed to add support for DW_LNE_set_discriminator 
(DWARF4) so I'm working on that 'as we speak'.

DavidAnderson

-- 
Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced."




From davea42@earthlink.net  Sat Dec 10 23:02:46 2011
From: davea42@earthlink.net (David Anderson)
Date: Sat, 10 Dec 2011 15:02:46 -0800
Subject: [Dwarf-Discuss] target address dependency of the FDE header in
 DWARF CFI
Message-ID: <4EE3E516.1070903@earthlink.net>

On 12/10/2011 10:04 AM, Eli Bendersky wrote:
>>> The CU specific address_size is used for that CU's  CIE/FDE set.
> David, could you elaborate - what to you mean by "that CU's CIE...".
> How do I know to which CU a CIE belongs?

Each FDE has an initial_location and  address_range indicating what 
instruction area
is applicable to the FDE.     That FDE refers to a specific CIE.     A 
CU also applies
to a range of addresses (some CU  DIEs have DW_AT_low_pc or 
DW_AT_ranges, but
certainly the functions in a CU will have addresses or address ranges).

So using an address as the key, find the CU applicable and the FDE 
applicable (which determines
the CIE applicable).   Hence finding a CU that 'owns' (speaking 
loosely)  a particular CIE.
In other words, the ownership is implicit in the DWARF data, not explicit.

It's normal for a single CU to have a single CIE, but that is a detail, 
and CIEs can
be split or merged without changing the notions here  (sharing a CIE 
across multiple
CUs could make things one's dwarf-reading code a little messier).

Normally the address-association here is really simple, and debuggers 
have all the lookup
tools in hand to do the association easily.

Hope this makes sense.  Always possible I'm just wrong :-)
DavidA.

-- 
It's important to ask yourself, when you're considering how much greener the grass is on the other side, if you've even been watering yours.  -- Unknown




From jan.kratochvil@redhat.com  Sat Dec 10 23:26:21 2011
From: jan.kratochvil@redhat.com (Jan Kratochvil)
Date: Sun, 11 Dec 2011 00:26:21 +0100
Subject: [Dwarf-Discuss] target address dependency of the FDE header in
 DWARF CFI
In-Reply-To: <4EE38B8B.4030305@earthlink.net>
References: <CAF-Rda9cw96xD6Vk5j8wpEU1szateuMm06hG6thR6sjVrVKCKQ@mail.gmail.com>
	<20111210120248.GA27591@host2.jankratochvil.net>
	<CAF-Rda94ngaEcm6Dw28jmYM7BTWMRQ+qqJdPkKFAx54YthYesA@mail.gmail.com>
	<20111210122640.GA28214@host2.jankratochvil.net>
	<CAF-Rda8kMg5d=VqTZBB2-yvWze_oejm1nq8Ss-E=PYEsNZZzww@mail.gmail.com>
	<4EE38B8B.4030305@earthlink.net>
Message-ID: <20111210232621.GA30097@host2.jankratochvil.net>

On Sat, 10 Dec 2011 17:40:43 +0100, David Anderson wrote:
> I happen to have a test object with .debug_frame and no .debug_info

That is a normal case on GNU/Linux, at least Fedoras, due to
gcc -fasynchronous-unwind-tables , .debug_frame is called .eh_frame there
(with minor format differences) and there are no .debug_* sections present.


Regards,
Jan



From gerald.rigdon@bsci.com  Mon Dec 12 14:01:58 2011
From: gerald.rigdon@bsci.com (Rigdon, Gerald STP)
Date: Mon, 12 Dec 2011 08:01:58 -0600
Subject: [Dwarf-Discuss] remove me
Message-ID: <3CD72B6D0BC0A14FAB6F6C3D81E42EE827C84E32F4@STPEXCMSP08.bsci.bossci.com>

Hi

Can you remove me from the mailing list.

Thx

Gerry

Gerald T. Rigdon
Fellow, Firmware Design Engineering
Boston Scientific Corporation
4100 Hamline Avenue North
St. Paul, MN 55112-5798 USA
Tel: 651.582.7106
gerald.rigdon at bsci.com
www.bostonscientific.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111212/8c1d5231/attachment.htm>


From davea42@earthlink.net  Tue Dec 13 18:44:33 2011
From: davea42@earthlink.net (David Anderson)
Date: Tue, 13 Dec 2011 10:44:33 -0800
Subject: [Dwarf-Discuss] GNU extensions - inconsistent?
Message-ID: <4EE79D11.5040000@earthlink.net>

I'm trying to make the dwarf.h I release complete (well, more complete) 
by keeping up with
GNU extensions, but what I see is confusing.

>From gcc-4.6.2/include/dwarf2.h

    /* Thread-safety annotations.
        See http://gcc.gnu.org/wiki/ThreadSafetyAnnotation .  */
     DW_AT_GNU_guarded_by    = 0x2108,
     DW_AT_GNU_pt_guarded_by = 0x2109,
     DW_AT_GNU_guarded       = 0x210a,
     DW_AT_GNU_pt_guarded    = 0x210b,
     DW_AT_GNU_locks_excluded = 0x210c,
     DW_AT_GNU_exclusive_locks_required = 0x210d,
     DW_AT_GNU_shared_locks_required = 0x210e,
     /* One-definition rule violation detection.
        See http://gcc.gnu.org/wiki/DwarfSeparateTypeInfo .  */
     DW_AT_GNU_odr_signature = 0x210f,
     /* Template template argument name.
        See http://gcc.gnu.org/wiki/TemplateParmsDwarf .  */
     DW_AT_GNU_template_name = 0x2110,

But http://gcc.gnu.org/wiki/TemplateParmsDwarf says DW_AT_GNU_template_name
is x2108   !     And http://gcc.gnu.org/wiki/ThreadSafetyAnnotation says 
nothing
about the DWARF extension values at all, it proposes values in the 
standard range, not
the extensions range.

I notice that gdb-7.3.1/include/dwarf2.h  matches that gcc header except 
the gdb version
has a few extra values,
DW_TAG_GNU_call_site etc.

I'll take the gdb one as governing, for the moment.

Any comments on this would be most welcome.
Thanks in advance.
David Anderson

-- 
It's fabulous! We haven't seen anything like it in the last half an hour!  -- Macy's




From jason@redhat.com  Tue Dec 13 18:57:36 2011
From: jason@redhat.com (Jason Merrill)
Date: Tue, 13 Dec 2011 13:57:36 -0500
Subject: [Dwarf-Discuss] GNU extensions - inconsistent?
In-Reply-To: <4EE79D11.5040000@earthlink.net>
References: <4EE79D11.5040000@earthlink.net>
Message-ID: <4EE7A020.4080304@redhat.com>

On 12/13/2011 01:44 PM, David Anderson wrote:
> /* Template template argument name.
> See http://gcc.gnu.org/wiki/TemplateParmsDwarf . */
> DW_AT_GNU_template_name = 0x2110,
>
> But http://gcc.gnu.org/wiki/TemplateParmsDwarf says DW_AT_GNU_template_name
> is x2108 !

Thanks, I've corrected the wiki.

Jason



From ccoutant@google.com  Tue Dec 13 19:03:05 2011
From: ccoutant@google.com (Cary Coutant)
Date: Tue, 13 Dec 2011 11:03:05 -0800
Subject: [Dwarf-Discuss] GNU extensions - inconsistent?
In-Reply-To: <4EE79D11.5040000@earthlink.net>
References: <4EE79D11.5040000@earthlink.net>
Message-ID: <CAHACq4q3+P3ZqcBM-WeHEqppbWFh2xfVChbn9F1YMo5GXQg8Cg@mail.gmail.com>

> And http://gcc.gnu.org/wiki/ThreadSafetyAnnotation says
> nothing
> about the DWARF extension values at all, it proposes values in the standard
> range, not
> the extensions range.

I've corrected this page, and added placeholders for the two values
not already defined there. I'll ask one of the annotalysis guys to
update that.

-cary



From tromey@redhat.com  Tue Dec 13 19:50:02 2011
From: tromey@redhat.com (Tom Tromey)
Date: Tue, 13 Dec 2011 12:50:02 -0700
Subject: [Dwarf-Discuss] GNU extensions - inconsistent?
In-Reply-To: <4EE79D11.5040000@earthlink.net> (David Anderson's message of
	"Tue, 13 Dec 2011 10:44:33 -0800")
References: <4EE79D11.5040000@earthlink.net>
Message-ID: <m37h20b6ad.fsf@fleche.redhat.com>

>>>>> "David" == David Anderson <davea42 at earthlink.net> writes:

David> I notice that gdb-7.3.1/include/dwarf2.h  matches that gcc header
David> except the gdb version
David> has a few extra values,
David> DW_TAG_GNU_call_site etc.

David> I'll take the gdb one as governing, for the moment.

The file is canonically maintained in GCC svn, then changes are merged
over to the gdb+binutils repository.

If you look at the files in releases, which one is newer will just
depend on which release happened later.

I checked just now and the files are still in sync in the development
repositories.


In the past, GNU was pretty lax about extensions.  Some were not
documented (DW_OP_GNU_uninit), some had the wrong names
(DW_TAG_format_label), etc.  We try to be better about it now.

Tom



