Re: [Qemu-devel] qemu-ppc can't run static uClibc binaries.

[Rob Landley]

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

  address@hidden:~$ git send-mail
  git: 'send-mail' is not a git-command. See 'git --help'.
  address@hidden:~$ git-send-mail
  bash: git-send-mail: command not found
  address@hidden:~$ 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.

I don't know if that's the _only_ problem the block of code I #ifdefed out was 
causing, but in general that whole section is specifically for BSD, and makes 
the behavior diverge from that of the Linux kernel.

> > If you prefer to make the requirements explicit, that works too, but a
> > comment might do just as well.  (I tend to prefer removing unnecessary
> > work Linux doesn't need done, rather than adding extra code to undo the
> > unnecessary work afterwards.  Force of habit from years on busybox and
> > such.)
>
> Well, I personally prefer to always use the same code paths whenever
> possible. That makes the code less prone to failure in odd configurations.
> And we have a lot of different combinations of those in Qemu.

Not all Linux binaries are going to run on BSD.  This is a case where the 
behavior of the two honestly diverges, and existing code depends on the actual 
linux-kernel behavior.

> But this is Riku's call. He's the linux-user maintainer.

Hi Riku!

/me makes puppy eyes at Riku.

> Alex

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds