Re: Debug ARM semihosting Thumb-2 binary

[Peter Maydell <peter.maydell@linaro.org>]

On 9 February 2012 13:08, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote:
> 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).

You shouldn't expect complaints about sound devices because the
stellaris boards don't have any sound devices.

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.

Using the 'realview-eb' platform is definitely a bad idea as it only
'works' because we don't really nail down the set of supported CPUs;
at some point in the future it may actively tell you this set of
command line options are a user error :-)

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

Coincidentally, Meador Inge from CodeSourcery posted a patch to the
QEMU list today which fixes the SIGINT issue:
http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02008.html
(not yet code reviewed, but I did a quick test and it does seem to
at least avoid the SIGINT problems.)
However speed of fread over the gdb syscall interface is absolutely
dire, it seems (from 'set debug remote 1') to be doing about one
data packet a second...

-- PMM