qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] functional ARM semihosting under GDB


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] functional ARM semihosting under GDB
Date: Wed, 19 Nov 2014 13:20:10 +0000

On 19 November 2014 13:06, Liviu Ionescu <address@hidden> wrote:
> I already explained, but will do it again.

Sorry if I missed that; there's a lot of mail on qemu-devel...

> first, we are talking about two completely different use cases.
>
> on the A profile you have a kernel, and when you start it, you 'append' to 
> the kernel path some options, and this is what you pass to the bootloader. 
> this has nothing to do with semihosting, the command line is always used by 
> the bootloader to start the kernel.
>
> on the M profile we do not have a kernel, but an image (that you
> do not want to accept as a different thing), and for normal
> emulation (i.e. without semihosting) we do not have any command
> line options.
>
> now comes semihosting.
>
> I do not know how you used semihosting for other platforms, but for
> arm, the current code breaks with faults, so I have my doubts it was
> really used (if it was, ok).

It works fine on the A and R profile cores. The problems you
are encountering are with M profile in particular.

> anyway, the current code uses the same strategy as for the bootloader,
> i.e. tries to use the kernel full path and concatenate with the
> 'append' string.
>
> on M profiles, the semihosting startup code cannot afford to allocate
> very large buffers for the command line, as for the A profiles, and
> usually only some tens of bytes are available; with the full paths
> as argv[0] this buffer is already not enough, and the semihosting
> code returns an error, without passing anything back to the application.

OK, this seems reasonable. You might want to pass an argv[0]
which wasn't the name of your binary anyway.

> so, for the A profile, nothing changes, use -kernel with the
> kernel name and -append with argv[1]...argv[n], as before.

I think we should support this new option in the same way for both
A profile and M profile.

> I do not know if it makes any sense to start a linux kernel with
> semihosting enabled

It does; there are kernel options to use semihosting for debug
console output.

>, but if it does, we can make the cmdline= optional, and, if
> missing and the -kernel and -append are present, we can apply
> the previous strategy, i.e. compose the long string from the
> full kernel path and the appended options.

Yes, we should do this. (We have to make cmdline= optional anyway,
to support old and previously working command lines.)

I should probably also look at getting these new arguments
to work for the linux-user qemu binary (which has its
own separate option parsing code).

> p.s. in my GNU ARM Eclipse branch I'll continue to use -image,
> and completely get rid of the misleading -kernel & -append
> options; I hope at a certain moment you'll accept qemu is
> also fit for non linux exclusive use cases.

I absolutely think we should work with non-linux use cases
(and that those are the majority on M profile). It's just
that the option for providing a binary image to load
happens to be called "-kernel" regardless of whether the
thing you're loading is a Linux kernel or some other binary.
That's unfortunate and confusing, but it's not missing
functionality, and it's really hard to change our command
line options without breaking existing working setups.
(And any change absolutely has to be a very carefully
considered design which accounts for all architectures QEMU
supports, otherwise we're just making difficulties for
ourselves in future. I actually would like to see this
confusion cleaned up, but it's really a very hard
problem to solve properly.)

-- PMM



reply via email to

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