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

  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
  

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
  

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'
  

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
  

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'