sim: frv: fix -Wincompatible-function-pointer-types warnings [PR sim/29752]
Some compilers warn in the frv code:
sem.c:24343:41: error: incompatible function pointer types passing
'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)')
to parameter of type
'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types]
This is due to frvbf_h_acc40U_set using UDI for setting the new value,
but using the common sim_queue_fn_di_write API which uses DI. The same
size, but different sign. We could change frvbf_h_acc40U_set to take a
DI without changing behavior in practice: the UDI is already passed via
the queue function which accepts a DI, and frvbf_h_acc40U_set already
casts the input to UDI before running any operations on it. However,
these files are all generated, so manual changes here would be reverted.
Seems like we can only change the register type for all APIs in the cpu
definition. This builds cleanly, and passes sim unittests. Not sure if
it's 100% the answer, but seems to be the best we have currently.
Bug: https://sourceware.org/PR29752
Use bool in opcodes
cpu/
* frv.opc: Replace bfd_boolean with bool, FALSE with false, and
TRUE with true throughout.
opcodes/
* sysdep.h (POISON_BFD_BOOLEAN): Define.
* aarch64-asm-2.c, * aarch64-asm.c, * aarch64-asm.h,
* aarch64-dis-2.c, * aarch64-dis.c, * aarch64-dis.h,
* aarch64-gen.c, * aarch64-opc.c, * aarch64-opc.h, * arc-dis.c,
* arc-dis.h, * arc-fxi.h, * arc-opc.c, * arm-dis.c, * bfin-dis.c,
* cris-dis.c, * csky-dis.c, * csky-opc.h, * dis-buf.c,
* disassemble.c, * frv-opc.c, * frv-opc.h, * h8300-dis.c,
* i386-dis.c, * m68k-dis.c, * metag-dis.c, * microblaze-dis.c,
* microblaze-dis.h, * micromips-opc.c, * mips-dis.c,
* mips-formats.h, * mips-opc.c, * mips16-opc.c, * mmix-dis.c,
* msp430-dis.c, * nds32-dis.c, * nfp-dis.c, * nios2-dis.c,
* ppc-dis.c, * riscv-dis.c, * score-dis.c, * score7-dis.c,
* tic6x-dis.c, * v850-dis.c, * vax-dis.c, * wasm32-dis.c,
* xtensa-dis.c: Replace bfd_boolean with bool, FALSE with false,
and TRUE with true throughout.
* m32r.cpu (HASH-PREFIX): Delete.
(duhpo, dshpo): New pmacros.
(simm8, simm16): Delete HASH-PREFIX attribute, define with dshpo.
(uimm3, uimm4, uimm5, uimm8, uimm16, imm1): Delete HASH-PREFIX
attribute, define with dshpo.
(uimm24): Delete HASH-PREFIX attribute.
* m32r.opc (CGEN_PRINT_NORMAL): Delete.
(print_signed_with_hash_prefix): New function.
(print_unsigned_with_hash_prefix): New function.
* xc16x.cpu (dowh): New pmacro.
(upof16): Define with dowh, specify print handler.
(qbit, qlobit, qhibit): Ditto.
(upag16): Ditto.
* xc16x.opc (CGEN_PRINT_NORMAL): Delete.
(print_with_dot_prefix): New functions.
(print_with_pof_prefix, print_with_pag_prefix): New functions.
opcodes cgen: remove use of PTR
Note that opcodes is regenerated with cgen commit d1dd5fcc38e reverted,
due to failure of bpf to compile with that patch applied.
.../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow]
57 | 64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } }
plus other similar errors.
cpu/
* mep.opc (print_tpreg, print_spreg): Delete unnecessary
forward declarations. Replace PTR with void *.
* mt.opc (print_dollarhex, print_pcrel): Delete forward decls.
opcodes/
* bpf-desc.c, * bpf-dis.c, * cris-desc.c,
* epiphany-desc.c, * epiphany-dis.c,
* fr30-desc.c, * fr30-dis.c, * frv-desc.c, * frv-dis.c,
* ip2k-desc.c, * ip2k-dis.c, * iq2000-desc.c, * iq2000-dis.c,
* lm32-desc.c, * lm32-dis.c, * m32c-desc.c, * m32c-dis.c,
* m32r-desc.c, * m32r-dis.c, * mep-desc.c, * mep-dis.c,
* mt-desc.c, * mt-dis.c, * or1k-desc.c, * or1k-dis.c,
* xc16x-desc.c, * xc16x-dis.c,
* xstormy16-desc.c, * xstormy16-dis.c: Regenerate.
or1k: Remove 64-bit support, it's not used and it breaks 32-bit hosts
Reported by Rich Felker when building on 32-bit hosts. Backwards jump
negative offsets were not calculated correctly due to improper 32-bit
to 64-bit zero-extension. The 64-bit fields are present because we
are mixing 32-bit and 64-bit architectures in our cpu descriptions.
Removing 64-bit fixes the issue. We don't use 64-bit, there is an architecture
spec for 64-bit but no implementations or simulators. My thought is if
we need them in the future we should do the proper work to support both
32-bit and 64-bit implementations co-existing then.
cpu/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
PR 25184
* or1k.cpu (arch or1k): Remove or64 and or64nd machs.
(ORBIS-MACHS, ORFPX32-MACHS): Remove pmacros.
(cpu or1k64bf, mach or64, mach or64nd): Remove definitions.
* or1kcommon.cpu (h-fdr): Remove hardware.
* or1korfpx.cpu (rDDF, rADF, rBDF): Remove operand definitions.
(float-regreg-insn): Remove lf- mnemonic -d instruction pattern.
(float-setflag-insn-base): Remove lf-sf mnemonic -d pattern.
(float-cust-insn): Remove "lf-cust" cust-num "-d" pattern.
(lf-rem-d, lf-itof-d, lf-ftoi-d, lf-madd-d): Remove.
or1k: Fix disassembly for little-endian binaries
There are some OpenRISC CPUs that have their binaries stored in
little-endian format. Using objdump to disassemble these is
problematic, as some instructions fail to disassemble, for example:
objdump -D -b binary -EB -m or1k test_be.bin
0: 18 60 07 27 l.movhi r3,0x727
4: a8 63 0e 00 l.ori r3,r3,0xe00
8: 9c 63 ff ff l.addi r3,r3,-1
c: bc 43 00 00 l.sfgtui r3,0
10: 13 ff ff fe l.bf 0x8
14: 44 00 48 00 l.jr r9
objdump -D -b binary -EL -m or1k test_le.bin
0: 27 07 60 18 *unknown*
4: 00 0e 63 a8 l.ori r3,r3,0xe00
8: ff ff 63 9c *unknown*
c: 00 00 43 bc l.sfgtui r3,0
10: fe ff ff 13 *unknown*
14: 00 48 00 44 l.jr r9
It was found that the hash function was using the still little-endian
buffer to extract the opcode used for the hash lookup. This didn't work
as it was pulling the wrong hashcode causing instruction lookup to fail.
Fix the hash function by using the normalized/byte-swapped value instead
of the buffer.
Signed-off-by: Stafford Horne <shorne@gmail.com>
or1k: Remove 64-bit support, it's not used and it breaks 32-bit hosts
Reported by Rich Felker when building on 32-bit hosts. Backwards jump
negative offsets were not calculated correctly due to improper 32-bit
to 64-bit zero-extension. The 64-bit fields are present because we
are mixing 32-bit and 64-bit architectures in our cpu descriptions.
Removing 64-bit fixes the issue. We don't use 64-bit, there is an architecture
spec for 64-bit but no implementations or simulators. My thought is if
we need them in the future we should do the proper work to support both
32-bit and 64-bit implementations co-existing then.
cpu/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
PR 25184
* or1k.cpu (arch or1k): Remove or64 and or64nd machs.
(ORBIS-MACHS, ORFPX32-MACHS): Remove pmacros.
(cpu or1k64bf, mach or64, mach or64nd): Remove definitions.
* or1kcommon.cpu (h-fdr): Remove hardware.
* or1korfpx.cpu (rDDF, rADF, rBDF): Remove operand definitions.
(float-regreg-insn): Remove lf- mnemonic -d instruction pattern.
(float-setflag-insn-base): Remove lf-sf mnemonic -d pattern.
(float-cust-insn): Remove "lf-cust" cust-num "-d" pattern.
(lf-rem-d, lf-itof-d, lf-ftoi-d, lf-madd-d): Remove.