This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Debug ARM semihosting Thumb-2 binary



On 09 Feb 2012, at 02:38, Matthew Gretton-Dann wrote:


On Wed, Feb 08, 2012 at 10:35:48PM +0000, Jonas Maebe wrote:

The full QEMU command line I use:


~/qemu/bin/qemu-system-arm -nographic -semihosting -M realview-eb - cpu cortex-m3 -kernel qsort_large -append "input_large.dat" -S -s

I think -M realview-eb -cpu cortex-m3 is not the best way of invoking qemu
as it generates a system with a Cortex-M3 but without the appropriate
interrupt controller. Try one of the Stellaris boards instead (use
-machine ? to get the actual command line).

I've now tried both -M lm3s811evb (Stellaris LM3S811EVB) and -M lm3s6965evb (Stellaris LM3S6965EVB) together with -cpu cortex-m3. Neither appears to work at all: there's no output (not even QEMU complaining that it can't open any sound devices, which it does instantaneously on startup if I choose the realview-eb platform).


If I start QEMU with a Stellaris platform selected and with -S -s (stop immediately on startup and wait for gdb) and attach gdb, the process is stopped at address 0 (instead of 0x8000). Removing the - semihosting switch does not change this (that would obviously fail as soon as a syscall were executed, but it doesn't get that far).

We need to diagnose whether this is a QEmu or GDB issue.

Yes, I'm also starting to wonder whether I might be QEMU rather than gdb that's going wrong...


What QEmu are you using?

The main site's 1.0 release, manually compiled directly from source (on Linux/x86-64).


Can you clarify whether this is Cortex-M3 specific? Does it happen if you
build for a Cortex-A profile CPU in ARM and Thumb state? What happens when
you run the image in QEmu without GDB attached?

If I run it in QEMU (with -m realview-eb -cpu cortex-m3) without gdb attached, everything works correctly (although occasionally not all output is printed, but that's probably a QEMU issue). I currently can't rebuild it for Cortex-A or anything else because our license for RVCT has expired and we're still in the process of renewing it.


Can you also provide a gdb trace of the remote protocol (use set debug
remote on before attaching to QEmu).


I've attached the remote log for the qsort_large program I've compiled. The binary was started with the following QEMU command line:

~/qemu/bin/qemu-system-arm -nographic -semihosting -M realview-eb -cpu cortex-m3 -kernel qsort_large -append "input_large.dat" -s -S

I've also attached the qsort_large binary itself, since it's pretty small (and it's from mibench, so it's freely distributable). The input_large.dat file that's required for input can be gotten from http://www.eecs.umich.edu/mibench/automotive.tar.gz (automotive/qsort/input_large.dat)

Thanks,


Jonas

Attachment: gdb-qsort_large-remote-log.txt
Description: Text document

Attachment: qsort_large.bz2
Description: BZip2 compressed data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]