Risc - V failures inside ld-undefined

["Clément Chigot" <chigot@adacore.com>]

Hi all,

I've been running the ld testsuite for Risc-V targets using a cross
compiler and I'm seeing some failures in "undefined".
PASS: undefined
FAIL: undefined function
FAIL: undefined line

As I'm using a custom gcc, I just want confirmation from the Risc-V
maintainers that these two tests are either failing or being skipped
on their side.
I've a patch fixing the testsuite for cross-compiler which might
explain why it has always been skipped until now and why this error
has been masked.

Note that I've investigated a bit and it seems to be related to
R_RISCV_ALIGN and the associated linker relaxation.
Instead of showing
  | ld: tmpdir/undefined.o: in function `function':
  | .../undefined.c:9: undefined reference to `this_function_is_not_defined'
the error is:
  | riscv64-elf-ld: tmpdir/undefined.o: in function `.Ltext0':
  | undefined.c:(.text+0x0): undefined reference to
`this_function_is_not_defined'

The idea is that "function" has an alignment of 2 and thus gas will
add NOP instructions and a R_RISCV_ALIGN relocation before it (within
tc-riscv.c:riscv_frag_align_code).
  | $ riscv64-elf-objdump -D tmpdir/undefined.o
  | 0000000000000000 <.Ltext0>:
  |   0:   0001                    nop
  |
  | 0000000000000002 <function>:
  |   2:   00000317                auipc   t1,0x0
  |   6:   00030067                jr      t1 # 2 <function>

When the linker will relax these NOPs (in
elfnn-riscv.c:riscv_relax_delete_bytes), it will correctly change the
relocation offset but not the DWARF information. Thus, when the error
is trying to get the nearest line using _bfd_dwarf2_find_nearest_line,
it ends up using a modified offset with non-modified DWARF information
and targets the wrong symbol.
I guess riscv_relax_delete_bytes can be improved to adjust the DWARF
part too. But I'm not familiar with this part of bfd and I'm not sure
it's even possible.
Otherwise, I guess XFAIL these tests should be fine as they are
similar to other XFAILs related to DWARF-2 (on arm-elf). Even if not
having a "function" being shown in the error might be problematic.

Anyway, the fact that I'm using a custom gcc shouldn't matter here but
I want to confirm that first.

Thanks,
Clément