Re: gdbstub and gbd segfaults on different instructions in userspaceemulation

Re: gdbstub and gbd segfaults on different instructions in userspaceemulation

[Libo Zhou]

On Tuesday, Oct 8, 2019 at 5:57 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Tue, 8 Oct 2019 at 10:50, Libo Zhou <zhlb29@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