Re: [Qemu-devel] Request for help with Qemu GDB for big-endian instructions (R4)

[Peter Maydell]

On 17 March 2016 at 15:09, Paul, Kaustav Kumar <address@hidden> wrote:
> If I understand correctly, inside the function
> gen_intermediate_code_internal(...), arm_ldl_code() reads
> the instruction-bytes according to PC and then disassemble.
> Initially, the output of this disassembly did not make much
> sense. It's only after I forced the last parameter (bswap_code)
> to 1 in the arm_ldl_code() function call that it started reading
> the instructions properly (execution moved further than before).

Yes, it looks like your board needs support for the ARMv7R
specific "instruction endianness" config option. You'll
need to write some code to support this: CPU property
corresponding to the CFGIE signal, your board code needs
to set the property, cpu reset function needs to use this
property flag to set the SCTLR.IE bit, update the bswap_code()
function to pay attention to SCTLR.IE. Luckily the IE bit is
constant so we don't need to give it a TB flag, but awkwardly
bswap_code() assumes it doesn't need to have an env pointer
so this will need some moderate restructuring and possibly
renaming functions a bit.

>  I was hoping that Qemu will pass this properly read instructions
> for gdb.

How QEMU handles reading instruction words from memory for
execution is completely unrelated to our GDB stub support.

> If this is what is happening, then as you have suggested, one
> option is to tell gdb client to expect instructions in BE format
> (config switch). I'll explore this option. Another will be to
> flip the byte-order before putting it on the gdb server socket.
> Can you please point me to exactly where gdb is reading these
> instructions?

GDB does not specifically ask to read instructions -- it just
reads memory (without caring whether it is data or code). You
need to deal with this part on the GDB end.

thanks
-- PMM