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 <ja...@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
