Re: gdbstub and gbd segfaults on different instructions in userspaceemulation

[Libo Zhou]

On Tuesday, Oct 8, 2019 at 5:57 PM, Peter Maydell <address@hidden> wrote:
>
> On Tue, 8 Oct 2019 at 10:50, Libo Zhou <address@hidden> 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