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: Liviu Ionescu
Subject: Re: [Qemu-devel] [PATCH] functional ARM semihosting under GDB
Date: Wed, 19 Nov 2014 15:06:45 +0200

On 19 Nov 2014, at 14:08, Peter Maydell <address@hidden> wrote:

> ... (Bear in mind that my target-arm.next
> branch is a rebasing branch, so you can't git merge
> or pull it; you need to fetch it and then rebase
> your patchstack on it.)

I currently have two more branches in my git, for each of the patches applied.

I planned to make another branch, based on the -semihosting-config branch, and 
add the cmdline patches there.
 
>>> my suggestion would be to extend the -semihosting-config
>>> option with cmdline="..." instead of adding a separate option
>>> (in my first patch I used -semihosting-cmdline).
> 
> On the A and R profile code path this command line
> is taken from the existing "-append" option. Is
> there a reason we can't just make the M profile
> code do the same thing?

I already explained, but will do it again.

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

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.

both the J-Link GDB server and the openOCD GDB server have a method of passing 
a string as an *entire*, self-contained, command line to be returned by the 
semihosting SYS_GET_CMDLINE call, including the argv[0], without using anything 
else like executable path.

I consider this strategy to be reasonable for QEMU too, and I would insist on 
considering it.


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

for semihosting, regardless of profile, but especially to satisfy the M profile 
limitations, I suggest an explicit: 

-semihosting-config target=native,cmdline="myTest 1 2 3"


I do not know if it makes any sense to start a linux kernel with semihosting 
enabled, 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. if 
it does not, we simplify things and always use cmdline="" (my favourite).


regards,

Liviu


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.









> 
> thanks
> -- PMM




reply via email to

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