Re: BUG: non-fixed-length ISAs are unsupported for now
Sergey Belyashov via Cgen <[email protected]> Thu, 13 Aug 2020 16:34:33 +0300
| Newsgroups | gmane.comp.tools.cgen.devel |
|---|---|
| Message-ID | <CAOe0RDy0rdTxQjw-6xwE6gj3SeDf8biyonuOW-6OQTJwz1zE5w@mail.gmail.com> |
Hi,
> Simply, make no change other than setting the base-insn large enough
> to contain all the opcode fields. Amongst all these cases, that seems
> to be 16 or perhaps 24 bits. I suggest trying 32.
When I increase base-insn-bitsize to 32 of ISA definition objdump
fails with: stack smashing error. Valgrind shows next backtrace:
00000000 <.text>:
*** stack smashing detected ***: terminated
==325050==
==325050== Process terminating with default action of signal 6 (SIGABRT)
==325050== at 0x48B718B: raise (raise.c:51)
==325050== by 0x4896858: abort (abort.c:79)
==325050== by 0x49013ED: __libc_message (libc_fatal.c:155)
==325050== by 0x49A39B9: __fortify_fail (fortify_fail.c:26)
==325050== by 0x49A3985: __stack_chk_fail (stack_chk_fail.c:24)
==325050== by 0x17BE43: default_print_insn (z80-dis.c:448)
==325050== by 0x17C0AA: print_insn_z80 (z80-dis.c:567)
==325050== by 0x131CB3: disassemble_bytes (objdump.c:2768)
==325050== by 0x13360E: disassemble_section (objdump.c:3340)
==325050== by 0x1A9E99: bfd_map_over_sections (section.c:1377)
==325050== by 0x133C2E: disassemble_data (objdump.c:3484)
==325050== by 0x137079: dump_bfd (objdump.c:4866)
But in C file RETI/RETN instructions are implemented as:
/* retn */
{
{ 0, 0, 0, 0 },
{ { MNEM, 0 } },
& ifmt_retn, { 0x132 } //why?!?
},
/* reti */
{
{ 0, 0, 0, 0 },
{ { MNEM, 0 } },
& ifmt_retn, { 0x13a } //why?!?
},
Definition of these instructions:
(dnf f-0 "whole byte 0" ((MACH z80) all-isas) 7 8)
(dnf f-1 "whole byte 1" ((MACH z80) all-isas) 15 8)
(dni retn "return from NMI handler" (all-isas UNCOND-CTI) "retn"
(+ (f-0 #xED) (f-1 #x45)) () ())
(dni reti "return from INT handler" (all-isas UNCOND-CTI) "reti"
(+ (f-0 #xED) (f-1 #x4D)) () ())
default-insn-bitsize in ISA definition is kept 8. If I set it 32 too,
then implementation of instructions looks correct, but stack smashing
exists too.
Best regards,
Sergey Belyashov