[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Request for help with Qemu GDB for big-endian instructi
Paul, Kaustav Kumar
Re: [Qemu-devel] Request for help with Qemu GDB for big-endian instructions (R4)
Thu, 17 Mar 2016 15:09:33 +0000
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
Thanks & regards,
From: Peter Maydell [mailto:address@hidden
Sent: Wednesday, March 16, 2016 7:53 PM
To: Paul, Kaustav Kumar <address@hidden>
Subject: Re: [Qemu-devel] Request for help with Qemu GDB for big-endian
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.
(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.