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

[Paul, Kaustav Kumar]

Hi Peter,

Thanks for your prompt response.

> First of all, please retry this with QEMU built from current git master.
> A lot of patches went in a few weeks ago to improve our big-endian support. 
> We may well still have some bugs, but there doesn't seem much point trying to 
> diagnose problems in the old code...

Good point. I have been using release 2.3.0. Need to try this out.

> (1) we don't implement an R4 model at all in QEMU (we do have an R5),
>    so are you using some out of tree patches for R4 support or are
>     you trying to run the code on an R5 CPU?

I grabbed the R4 init function from Xilinx Qemu repo. Though not quite sure if 
it is fully implemented/tested to work there or not.

> (2) which board model are you using? One in QEMU mainline or an out
>     of tree one? What is your QEMU command line?

It is essentially a completely new board. I started with the vexpress (with A9) 
as a base reference and had to modify all memory regions, device addresses 
along with a number of custom device implementations. I am confident about the 
new device implementations as I have already tested them on yet another board 
using A9. However, not quite so with the memory regions as R4 uses MPU, and 
this is the first time I had to use aliased regions for the DRAM. Looking at 
the line where Qemu crashes trying to run the firmware, it seems to be in the 
configuration of MPU. As I mentioned earlier, the firmware code has been tested 
to run on the actual hardware. So, it must be how I am defining the regions in 
the board model, aliased DRAM as well as ITCM/DTCM. Without the debugging 
capability I can't put my finger on it.

> Regarding gdb, QEMU just provides facilities for reading and writing memory, 
> so if asking gdb to do a memory dump shows correct data but disassembly does 
> not, then the problem is at the gdb end (probably a config switch);

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).  I was hoping 
that Qemu will pass this properly read instructions for gdb. If gdb is given 
just the raw data (i.e. instructions read assuming LE format) then it makes 
sense. GDB client probably doesn't have any idea that it should interpret them 
in BE format and defaults to LE. If I open the object file directly in gdb and 
disassemble, then it already knows the format from the ELF header section and 
that's why able to read the instruction properly in that case.

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?

Thanks & regards,
Kaustav

-----Original Message-----
From: Peter Maydell [mailto:address@hidden 
Sent: Wednesday, March 16, 2016 7:53 PM
To: Paul, Kaustav Kumar <address@hidden>
Cc: address@hidden
Subject: Re: [Qemu-devel] Request for help with Qemu GDB for big-endian 
instructions (R4)

On 16 March 2016 at 10:06, Paul, Kaustav Kumar <address@hidden> wrote:
> The firmware is compiled for Cortex-R4, runs ThreadX OS and is 
> configured to use both instructions and data in big-endian (BE32 ?) format.

The Cortex-R4 is an ARMv7 CPU, and so only supports BE8.

> The code is
> compiled with GHS toolchain. I understand that out of the box, GDB 
> will not be able to do source code debugging. However, I expected that 
> it’ll at least be able to do assembly level debugging. We have another 
> ASIC with Cortex-A9 configured for BE8, also running ThreadX. And it 
> does work at assembly level.

First of all, please retry this with QEMU built from current git master.
A lot of patches went in a few weeks ago to improve our big-endian support. We 
may well still have some bugs, but there doesn't seem much point trying to 
diagnose problems in the old code...

That said, if your R4 is configured to use big-endian instruction order 
(presumably by the CFGIE signal being set high), then you're probably running 
into the fact that QEMU does not implement the
(PMSAv7) SCTLR.IE bit which allows big-endian instructions for R profile.

Further questions:
 (1) we don't implement an R4 model at all in QEMU (we do have an R5),
     so are you using some out of tree patches for R4 support or are
     you trying to run the code on an R5 CPU?
 (2) which board model are you using? One in QEMU mainline or an out
     of tree one? What is your QEMU command line?

Regarding gdb, QEMU just provides facilities for reading and writing memory, so 
if asking gdb to do a memory dump shows correct data but disassembly does not, 
then the problem is at the gdb end (probably a config switch); you probably 
need to ask a gdb person about that.

thanks
-- PMM