32-bit --enable-targets=all build breakage

[Alan Modra]

On Fri, Nov 12, 2021 at 02:51:26AM +0800, Nelson Chu wrote:
> Hi Alan, Hi Luis,
> 
> This should be the same problem as the commit
> ba9b3ef5ee666467b67780e81f868c432f4fc56d.

Yes.

> I figured that I cannot
> just move the riscv architecture parser to the bfd/cpu-riscv.c, since
> the riscv_add_subset will use the xmalloc to create the element of the
> linked list, but the xmalloc is disallowed for libopcodes.
> 
> Then I tried to add the elfxx-riscv.lo and elfxx-riscv.c into the
> BFD32_BACKENDS and BFD32_BACKENDS_CFILES, but I get the unexpected
> error,
> 
> /scratch/zakkc/nelsonc/binutils-gdb/bfd/elfxx-riscv.c:275:3: warning:
> left shift count >= width of type [enabled by default]
>    HOWTO (R_RISCV_CALL_PLT,  /* type */
>    ^
> /scratch/zakkc/nelsonc/binutils-gdb/bfd/elfxx-riscv.c:275:3: error:
> initializer element is not constant
> /scratch/zakkc/nelsonc/binutils-gdb/bfd/elfxx-riscv.c:275:3: error:
> (near initialization for 'howto_table[19].dst_mask')
> 
> Seems like the error is caused by the dst_mask of the R_RISCV_CALL and
> R_RISCV_CALL_PLT in the reloc_howto_struct table.  The dst_mask of the
> two relocations are - ENCODE_UTYPE_IMM (-1UL) | ((bfd_vma)
> ENCODE_ITYPE_IMM (-1UL) << 32), and they should overflow for the
> 32-bit host machine...
> 
> Jim Wilson had suggested a solution - we could link the elfxx-riscv.lo
> and elfxx-riscv.c for BFD32_BACKENDS and BFD32_BACKENDS_CFILES, and
> then we handle the dst_mask of the R_RISCV_CALL and R_RISCV_CALL_PLT
> in the bfd/elfnn-riscv.c:perform_reloc specially, and then we don't
> need the dst_mask in the reloc_howto_struct anymore.  I will try this
> solution first, since this looks reasonable and good.  It should be
> the best choice for us so far.
> 
> Sorry for causing this problem again, but I think we do need the riscv
> arch parser workable for the disassembler, since not only the mapping
> symbols, but also the zfinx extension need it.

I'll note that there isn't any point in having opcodes disassembler
support for a target without the ability in bfd to open object files
for that target.  Ideally we'd be a bit more selective in the files we
compile into libopcodes..

-- 
Alan Modra
Australia Development Lab, IBM