Re: Debug ARM semihosting Thumb-2 binary

[Jonas Maebe <jonas dot maebe at elis dot ugent dot be>]

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


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:
>
> http://patchwork.ozlabs.org/patch/141867/


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
[etc]
***

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.

Thanks,


Jonas

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