On Tuesday, Oct 8, 2019 at 5:57 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Tue, 8 Oct 2019 at 10:50, Libo Zhou <zhl...@foxmail.com> wrote: >> >> Is there any follow-up guys? Help would be appreciated. > > Not really. You're using a locally modified QEMU that > you appear to be trying to get to support some non-standard > variant CPU, so you're on your own for trying to debug > it beyond the sort of general suggestions I already > gave you, I'm afraid.
Okay. Thank you for your help recently anyway :) I am suspecting that my own tool chain doesn't work with QEMU out of the box. In that case the mailing list probably couldn't help. However, may I still ask for some advice on workaround? I think it's too early for me to give up on QEMU. When I used my objdump -d to disassemble the ELF produced by my custom gcc, it only contained the <main> section in the *entire* ELF; When I used the official tool chain from MIPS to compile the same C source, the objdump -d gave me a lot of sections, such as <__libc_start_main>, etc. And the objdump is consistent with the -d in_asm logging option from QEMU. Hence, I think this could be the reason why only changing the opcode fields doesn't work. I only changed the ISA, but I didn't change other parts of the CPU to accommodate my needs. As you mentioned, I have been trying to support a non-standard variant CPU. So, I'd like to give it a try to create my own target/mycpu, which has very limited functionality. Its complexity is much lower than all the variants of MIPS. Nonetheless, how would you evaluate the effort needed to do this from scratch? - Libo Zhou
