On 16.02.2010, at 19:31, Rob Landley wrote: > On Monday 15 February 2010 07:01:02 Alexander Graf wrote: >> On 15.02.2010, at 13:58, Rob Landley wrote: >>> On Monday 15 February 2010 05:19:24 Alexander Graf wrote: >>>> On 15.02.2010, at 12:10, Rob Landley wrote: >>>>> On Sunday 14 February 2010 08:41:00 Alexander Graf wrote: >>>>>> So the only case I can imagine that this breaks anything is that >>>>>> uClibc requires register state to be 0. >>>>> >>>>> Yes, r3 (which is the exit code from the "exec" syscall, and thus 0 if >>>>> it worked). In the BSD layout, it's argc (which can never be 0). >>>>> >>>>> http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00720.html >>>> >>>> So what you really want is something like >>>> >>>> #ifdef CONFIG_LINUX_USER >>>> /* exec return value is always 0 */ >>>> env->gpr[3] = 0; >>>> #endif >>>> >>>> just after the #endif in your patch. If you had inlined your patch I >>>> could've commented it there. >>> >>> Unfortunately kmail plays fast and loose with whitespace when I inline >>> stuff. (Not always, but I can't tell by inspection when it's decided it >>> was hungry for tabs or wanted to throw in that horrible UTF8 escaped >>> whitespace.) >> >> git-send-mail is your friend :-). > > No git command is my friend. The user interface of that monstrosity should > be > <strike>condemned</strike> banished with full bell book and dribbly candles. > > And I dunno how it would interface with kmail. (No other program on my > laptop > has the ssh tunnel to my mail server set up so it can send anything.) But > out > of curiosity... > > land...@driftwood:~$ git send-mail > git: 'send-mail' is not a git-command. See 'git --help'. > land...@driftwood:~$ git-send-mail > bash: git-send-mail: command not found > land...@driftwood:~$ git send mail > git: 'send' is not a git-command. See 'git --help'. > > Since it's unlikely that this could send a patch I haven't checked into git > (and I generally treat git as a read-only resource), learning more about it > goes on the todo list I expect. > >>> I didn't explicitly set it because they're initialized to zero in >>> function main() on line 2654 of linux-user/main.c. (Any regs we don't >>> explicitly set to some other value start out zeroed in qemu.) >> >> So it should work already? > > *shrug* It doesn't. > > Let's see, one of the lines I #ifdefed out (line 535-ish of linux- > user/elfload.c) is: > > get_user_ual(_regs->gpr[3], pos); > > Rummage, rummage... get_user_ual() is a wrapper for get_user() which is a > wrapper for __get_user() which assigns to its first argument. So yeah, > that's > setting _regs->gpr[3] to a nonzero value.
Well I was wondering on the order of execution. If main() already sets the GPRs to 0 it should be 0. I assume the elf reading code comes after that? If so, your patch looks correct. Alex