This is the mail archive of the 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 20 Feb 2012, at 17:21, Peter Maydell wrote:

The reason this isn't working for you is that QEMU's M3 model doesn't
pay any attention to the entry point in an ELF file -- it expects that
you feed it an ELF image which starts at address zero and includes the
M profile vector table (from which it will pull the starting PC and SP).

Not supporting "load ELF file and use its entry point as the starting
PC" is arguably a missing feature (although you have to answer the question
of 'so what should the starting SP be' if you want to support this).
However since QEMU's M profile support is basically in the 'odd fixes'
state this isn't likely to be improved in the near future, so the
simplest thing is for you to just generate an ELF file of the right

I see, thanks. I'm currently waiting for a renewal of our compiler license though, so right now that's unfortunately not an option (I can use objcopy extract a binary dump from my binary, but then it misses the vector table). Since I'm not writing an OS but am running very simple minibenchmarks (mibench), I assume that in general things should work fine though. Except, of course, if the bkpt instructions require extra support not provided by the realview-eb platform...

There's now a version 2 of the patch which attacks the problem
in a slightly different way and fixes both the SIGINT problems and
also the occasional stalls which were causing semihosting read/write
performance to be so poor:

Thanks. I tested it (with the realview-eb platform) on top of Qemu 1.0, but unfortunately it doesn't completely solve the problem yet for me:
a) gdb no longer stops with SIGINT whenever a bkpt is executed, which is good
b) however, the syscalls still don't seem to get executed, or at least do not return the proper result

Without gdb attached, the qsort_large binary shows this output:

Sorting 50000 vectors based on distance from the origin.

25138398 28611231 9838998

With gdb attached, this is the output:

Sorting 0 vectors based on distance from the origin.

So it seems the reading of the input file fails. FWIW, this is the same output I got before the patch, except that GDB then also stopped with a SIGINT every time a syscall/bkpt was executed. I've attached the new target remote debug output from gdb.

If this is due to me using the realview-eb platform, then I guess I'll just have to do without debugging past the first syscall until I can regenerate my binaries.



Attachment: target-remote-v2.txt
Description: Text document

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