dwarf2out: Fix -gsplit-dwarf on riscv or other non-.uleb128 targets [PR99090]

Hi!

As mentioned in the PR, riscv* only supports .uleb128 with constant
arguments, doesn't support difference of two labels because of aggressive
linker relaxations.  But I bet various other targets, especially those not
using GNU assembler, might suffer from the same problem.
As the FIXME comment in output_loc_list indicates, we ICE on
-gsplit-dwarf on those targets whenever we need .debug_loclists, because
we only emit DW_LLE_startx_length which requires working .uleb128 delta
of 2 code section labels.  We can't use DW_LLE_base_addressx
once followed by DW_LLE_offset_pair either because the latter suffers
from the same issue - need .uleb128 difference of code section labels
(and in that case not just for the second operand but also for the first).

So, this patch implements what the comment said and emits DW_LLE_startx_endx
instead, which wastes more space in .debug_addr, but will work.

Bootstrapped/regtested on x86_64-linux and i686-linux and as written in the
PR, Jim has tested it on riscv*linux.  Ok for trunk?

BTW, for HAVE_AS_LEB128 -gdwarf-5 -gsplit-dwarf, maybe we should consider
instead of always emitting DW_LLE_startx_length do all the optimizations
that we do for HAVE_AS_LEB128 -gdwarf-5, or at least a subset of them.
For !have_multiple_function_sections, we in that case emit just
DW_LLE_offset_pair (that can certainly be a win for small TUs, we wouldn't
need any .debug_addr entry in that case; on the other side, just using
DW_LLE_offset_pair can be harmful for very large TUs especially if the
loclist has many entries, emitting in that case a single DW_LLE_base_address
or for -gsplit-dwarf DW_LLE_base_addressx followed by DW_LLE_offset_pair
might be much smaller), and for have_multiple_function_sections figuring
out if DW_LLE_base_address followed by DW_LLE_offset_pair entries
or DW_LLE_start_length is bettter.  So perhaps a middle-ground for
-gsplit-dwarf would be to always do the have_multiple_function_sections
behavior, i.e. DW_LLE_base_addressx followed by DW_LLE_offset_pair vs.
DW_LLE_startx_length decisions based on the ranges and their counts.
And perhaps dwz could optimize afterwards, on linked binaries or shared
libraries it knows all the offsets and could figure out optimal DW_LLE_*.

2021-02-26  Jakub Jelinek  <jakub@redhat.com>

	PR debug/99090
	* dwarf2out.c (dw_loc_list_struct): Add end_entry member.
	(new_loc_list): Clear end_entry.
	(output_loc_list): Only use DW_LLE_startx_length for -gsplit-dwarf
	if HAVE_AS_LEB128, otherwise use DW_LLE_startx_endx.  Fix comment
	typo.
	(index_location_lists): For dwarf_version >= 5 without HAVE_AS_LEB128,
	initialize also end_entry.


	Jakub

On 2/27/21 3:21 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> As mentioned in the PR, riscv* only supports .uleb128 with constant
> arguments, doesn't support difference of two labels because of aggressive
> linker relaxations.  But I bet various other targets, especially those not
> using GNU assembler, might suffer from the same problem.
Yea.  I'm going to be working on a target with similar constraints
soon.  The 32bit PA hpux port has similar issues, but can at least emit
suitable relocations to make this work.
> As the FIXME comment in output_loc_list indicates, we ICE on
> -gsplit-dwarf on those targets whenever we need .debug_loclists, because
> we only emit DW_LLE_startx_length which requires working .uleb128 delta
> of 2 code section labels.  We can't use DW_LLE_base_addressx
> once followed by DW_LLE_offset_pair either because the latter suffers
> from the same issue - need .uleb128 difference of code section labels
> (and in that case not just for the second operand but also for the first).
>
> So, this patch implements what the comment said and emits DW_LLE_startx_endx
> instead, which wastes more space in .debug_addr, but will work.


>
> Bootstrapped/regtested on x86_64-linux and i686-linux and as written in the
> PR, Jim has tested it on riscv*linux.  Ok for trunk?
>
> BTW, for HAVE_AS_LEB128 -gdwarf-5 -gsplit-dwarf, maybe we should consider
> instead of always emitting DW_LLE_startx_length do all the optimizations
> that we do for HAVE_AS_LEB128 -gdwarf-5, or at least a subset of them.
> For !have_multiple_function_sections, we in that case emit just
> DW_LLE_offset_pair (that can certainly be a win for small TUs, we wouldn't
> need any .debug_addr entry in that case; on the other side, just using
> DW_LLE_offset_pair can be harmful for very large TUs especially if the
> loclist has many entries, emitting in that case a single DW_LLE_base_address
> or for -gsplit-dwarf DW_LLE_base_addressx followed by DW_LLE_offset_pair
> might be much smaller), and for have_multiple_function_sections figuring
> out if DW_LLE_base_address followed by DW_LLE_offset_pair entries
> or DW_LLE_start_length is bettter.  So perhaps a middle-ground for
> -gsplit-dwarf would be to always do the have_multiple_function_sections
> behavior, i.e. DW_LLE_base_addressx followed by DW_LLE_offset_pair vs.
> DW_LLE_startx_length decisions based on the ranges and their counts.
> And perhaps dwz could optimize afterwards, on linked binaries or shared
> libraries it knows all the offsets and could figure out optimal DW_LLE_*.
>
> 2021-02-26  Jakub Jelinek  <jakub@redhat.com>
>
> 	PR debug/99090
> 	* dwarf2out.c (dw_loc_list_struct): Add end_entry member.
> 	(new_loc_list): Clear end_entry.
> 	(output_loc_list): Only use DW_LLE_startx_length for -gsplit-dwarf
> 	if HAVE_AS_LEB128, otherwise use DW_LLE_startx_endx.  Fix comment
> 	typo.
> 	(index_location_lists): For dwarf_version >= 5 without HAVE_AS_LEB128,
> 	initialize also end_entry.
OK
jeff