https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119367
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is because llvm doesn't support location views in .loc as directive, so
HAVE_AS_DWARF2_DEBUG_VIEW is false on gcn during configure.
And the fallback added in r8-6657 uses DW_LNS_fixed_advance_pc which needs a
2-byte operand.
So, either we switch gcn to use binutils, or convince LLVM to support location
views in .loc as directive, or somehow from insn length figure out there might
be a too large distance and try to do something different in that case.
Though, the comment says:
/* Output a Fixed Advance PC; the target PC is the label index; the
base PC is the previous LI_adv_address or LI_set_address entry.
We only use this when emitting debug views without assembler
support, at explicit user request. Ideally, we should only use
it when the offset might be zero but we can't tell: it's the only
way to maybe change the PC without resetting the view number. */
and the LI_set_address says
/* ??? Unfortunately, we have little choice here currently, and
must always use the most general form. GCC does not know the
address delta itself, so we can't use DW_LNS_advance_pc. Many
ports do have length attributes which will give an upper bound
on the address range. We could perhaps use length attributes
to determine when it is safe to use DW_LNS_fixed_advance_pc. */
So, if we can reach > 65535 differences in address for LI_adv_address, wonder
if we don't need to use LI_set_address instead (but dunno whether that resets
view number or not).
