qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Request for help with Qemu GDB for big-endian instructions


From: Paul, Kaustav Kumar
Subject: [Qemu-devel] Request for help with Qemu GDB for big-endian instructions (R4)
Date: Wed, 16 Mar 2016 10:06:33 +0000

Hi,

Here is an issue I am facing while trying to debug firmware (host) with GDB on Qemu (invoked with options -s -S) .

 

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 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.

 

However, when I load the R4 code, it decodes the instructions all wrong due to big-endian insn config. As a temporary work-around, inside the function gen_intermediate_code_internal() in translate.c, I changed the line-

unsigned int insn = arm_ldl_code(env, dc->pc, dc->bswap_code)

to-

unsigned int insn = arm_ldl_code(env, dc->pc, 1)

 

After this change, Qemu started reading the instructions properly. However, it fails after executing a few instructions. It is probably due to MPU config in the startup code or in the memory layout of the board and this is where I need the debugging capability.

Even though Qemu now executes the instruction properly, GDB still shows wrong information. This has got me confused. On top of that, if I open the same object file in Linaro-gdb, it actually reads the instructions(big-endian)  properly, without requiring any change/settings/options. So, my question is, if GDB inherently has the capability of understanding big-endian instructions and Qemu has been modified to understand them as well, why is debugging in Qemu is still having the same problem.

 

I am attaching 3 screenshots to help understand the issue-

1.       GHS_toolchain.png - Object file opened in GHS toolchain.

2.       linaro_gdb.png - Object file directly opened in linaro-gdb and disassembled.

3.       qemu_gdb.png - Object file loaded in Qemu and connected to linaro-gdb.

 

I’ll really appreciate if someone can provide a clue about what is going on here or what am I doing wrong. Please feel free to ask if you need more information.

FYI, the compiled code has already been tested to run on the actual hardware with JTAG debugger. Rebuilding the firmware with (little-instruction + little-data) or (little-instruction + big-data) is not an option. Our primary objective is to build a simulator that can run the firmware without any hacks.

 

Thanks & regards,

Kaustav

 

 

Attachment: GHS_toolchain.png
Description: GHS_toolchain.png

Attachment: qemu_gdb.png
Description: qemu_gdb.png

Attachment: linaro_gdb.png
Description: linaro_gdb.png


reply via email to

[Prev in Thread] Current Thread [Next in Thread]