Patchwork [2/4] Add a dwarf unit type to represent 24 bit values.

login
register
mail settings
Submitter John Darrington
Date Sept. 26, 2018, 5:41 p.m.
Message ID <20180926174157.mw5eocxlfmgliua7@jocasta.intra>
Download mbox | patch
Permalink /patch/29555/
State New
Headers show

Comments

John Darrington - Sept. 26, 2018, 5:41 p.m.
After discussion with the gcc folks, it seems that there is an easier
and much simpler solution, which I'm attaching.

J'

On Fri, Sep 07, 2018 at 03:50:00PM -0600, Tom Tromey wrote:
     >>>>> "John" == John Darrington <john@darrington.wattle.id.au> writes:
     
     John> 	* include/dwarf2.h (enum dwarf_unit_type) [DE_EH_PE_udata3]: New member.
     John> ---
     John>  include/dwarf2.h | 1 +
     John>  1 file changed, 1 insertion(+)
     
     I'm afraid I didn't look at the earlier discussion of this.
     
     dwarf2.h is canonically maintained in the gcc repository.  So, any
     change here has to be sent to gcc-patches and be committed there first.
     Then the patch can be applied to gdb -- this counts as obvious (IMO).
     
     Tom
Simon Marchi - Sept. 27, 2018, 2:53 a.m.
On 2018-09-26 13:41, John Darrington wrote:
> After discussion with the gcc folks, it seems that there is an easier
> and much simpler solution, which I'm attaching.
> 
> J'

Err can you explain how this works, or link to the gcc discussion if 
it's explained there?  I must be missing something, because as far as I 
understand, this will read 4 bytes when reading an address, when I 
suppose it's encoded with 3 bytes in the DWARF info, isn't it?

Simon
John Darrington - Sept. 27, 2018, 5:49 a.m.
On Wed, Sep 26, 2018 at 10:53:34PM -0400, Simon Marchi wrote:
     On 2018-09-26 13:41, John Darrington wrote:
     > After discussion with the gcc folks, it seems that there is an easier
     > and much simpler solution, which I'm attaching.
     > 
     > J'
     
     Err can you explain how this works, or link to the gcc discussion if it's
     explained there?  I must be missing something, because as far as I
     understand, this will read 4 bytes when reading an address, when I
     suppose it's encoded with 3 bytes in the DWARF info, isn't it?
     
     Simon

The relevant discussion is here: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00712.html

The bottom line is that the dwarf address size does not need to
correspond to the machine address size (and in general it does not) - 
it just needs to be at least as long.

J'
Simon Marchi - Sept. 27, 2018, 5:53 p.m.
On 2018-09-27 01:49, John Darrington wrote:
> On Wed, Sep 26, 2018 at 10:53:34PM -0400, Simon Marchi wrote:
>      On 2018-09-26 13:41, John Darrington wrote:
>      > After discussion with the gcc folks, it seems that there is an 
> easier
>      > and much simpler solution, which I'm attaching.
>      >
>      > J'
> 
>      Err can you explain how this works, or link to the gcc discussion 
> if it's
>      explained there?  I must be missing something, because as far as I
>      understand, this will read 4 bytes when reading an address, when I
>      suppose it's encoded with 3 bytes in the DWARF info, isn't it?
> 
>      Simon
> 
> The relevant discussion is here:
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00712.html
> 
> The bottom line is that the dwarf address size does not need to
> correspond to the machine address size (and in general it does not) -
> it just needs to be at least as long.

After a short discussion with John on IRC, what I understand is that the 
debug info he is dealing with encodes the 24-bit addresses on 32-bits, 
with the most significant byte equal to zero.  Therefore that revised 
patch looks ok to me.  I would just ask you to add a comment explaining 
that this "case" exists for producer XYZ on S12Z, which encodes 24 bit 
addresses on 32 bits.  Maybe that in the future somebody will stumble on 
a producer that encodes 24 bit addresses on 24 bits.  Having an 
explanation for why things are the way they are will help.

Thanks,

Simon
John Darrington - Sept. 28, 2018, 4:03 p.m.
On Thu, Sep 27, 2018 at 01:53:35PM -0400, Simon Marchi wrote:
     
     After a short discussion with John on IRC, what I understand is that the
     debug info he is dealing with encodes the 24-bit addresses on 32-bits,
     with the most significant byte equal to zero.  Therefore that revised
     patch looks ok to me.  I would just ask you to add a comment explaining
     that this "case" exists for producer XYZ on S12Z, which encodes 24 bit
     addresses on 32 bits.  Maybe that in the future somebody will stumble on
     a producer that encodes 24 bit addresses on 24 bits.  Having an
     explanation for why things are the way they are will help.
     

When I look at the situation in more detail a number of things are
apparent:

1.  The dwarf .frame_debug CFI information does indeed code these values
    as 32 bits.

2.  This would seem to contradict the dwarf 2.0 standard which says they are 
    "addressing-unit sized values".

3.  objdump expects these values to be 24 bits.

4.  However readelf expects them to be 32 bits.

5.  Notwithstanding the above, the produced dwarf which I have, contains
    lots of FDE entries, with lots of CFIs.  However the contents of all 
    CFIs are empty.   Consequently it's of little use.

Given the above, I think the best course of action is to do nothing, on 
this point.

So I'll do without a dwarf unwinder until there's a producer which
actually produces something useful.

J'

Patch

From f2948209c0292d836ade4dda222c1ffe4aa9abe4 Mon Sep 17 00:00:00 2001
From: John Darrington <john@darrington.wattle.id.au>
Date: Wed, 19 Sep 2018 10:28:43 +0200
Subject: [PATCH] GDB: Don't abort if the address size is 3 bytes.

* gdb/dwarf2-frame.c (encoding_for_size): Deal with the case where size == 3.
---
 gdb/dwarf2-frame.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gdb/dwarf2-frame.c b/gdb/dwarf2-frame.c
index 55ab081bff..dfae2aaf97 100644
--- a/gdb/dwarf2-frame.c
+++ b/gdb/dwarf2-frame.c
@@ -1527,6 +1527,7 @@  encoding_for_size (unsigned int size)
     {
     case 2:
       return DW_EH_PE_udata2;
+    case 3:
     case 4:
       return DW_EH_PE_udata4;
     case 8:
-- 
2.11.0