Hi Jakub,

On Thu, 2020-09-24 at 21:39 +0200, Jakub Jelinek wrote:
> On Thu, Sep 24, 2020 at 06:25:54PM +0200, Mark Wielaard wrote:
> > @@ -7209,6 +7225,8 @@ partition_dups_1 (dw_die_ref *arr, size_t
> > vec_size,
> >  	   /* CU Header: address_size (ubyte).
> >  	      1 byte.  */
> >  	   + 1
> > +	   /* DWARF5 CU header: unit_type (ubyte).  */
> > +	   + die_cu (arr[i])->cu_version >= 5 ? 1 : 0
> >  	   /* CU Root DIE: abbreviation code (unsigned LEB128).
> >  	      1 or more bytes.  Optimistically assume 1.  */
> >  	   + 1
> 
> The above looks incorrect.
> 4 + 2 + 4 + 1 + x >= 5 ? 1 : 0 + 1 + 4 + 4
> is (11 + x >= 5) ? 1 : (0 + 1 + 4 + 4)
> rather than
> 4 + 2 + 4 + 1 + (x >= 5 ? 1 : 0) + 1 + 4 + 4
> we need there.  So, please add ()s around.

Groan, how embarrassing. Fixed.

> > @@ -10451,7 +10473,8 @@ compute_abbrevs (DSO *dso)
> >        dw_die_ref *intracuarr, *intracuvec;
> >        enum dwarf_form intracuform = DW_FORM_ref4;
> >        dw_die_ref child, *lastotr, child_next, *last;
> > -      unsigned int headersz = cu->cu_kind == CU_TYPES ? 23 : 11;
> > +      unsigned int headersz = (cu->cu_kind == CU_TYPES
> > +			       ? 23 : (cu->cu_version >= 5 ? 12 : 11));
> 
> Is the DWARF 5 .debug_info types header also 23 bytes long?

DW_UT_type units are length (4) + version (2) + unit_type (1) +
ptr_size (1) + abbrev_off (4) + signature (8) + type_off (4) = 28 bytes
long. But we don't support those yet. When we do we need to distinguish
between CU_TYPES_4 and CU_TYPES_5 because they can be both present.

For my first pass of adding DWARF5 support I was not planning on doing
CU_TYPES_5 because as far as I know nothing produces it at the moment.
But it shouldn't be too hard to add it at the same level that dwz
supports CU_TYPES_4.

Is the patch (with the above fix) as attached for just compile and
partial DWARF5 unit headers OK for now?

Cheers,

Mark