Re: [Fwd: Debugging execve problems]

[Samuel Thibault]

Svante Signell, le Sat 07 Jan 2012 17:58:31 +0100, a écrit :
> On Sat, 2012-01-07 at 15:48 +0100, Samuel Thibault wrote:
> > Svante Signell, le Sat 07 Jan 2012 15:43:46 +0100, a écrit :
> 
> > > 2) How come execve calls a shell script works with . in PATH?
> > 
> > Sure they do, the problem is not there, but in the value of $0.
> 
> Well when running the test.{c,sh} program under GNU/Linux $0 is test.sh,
> with and without having . in PATH.

I'm not talking about Linux, but about GNU/Hurd. When run from
execv, $0 in a shell script in hurd will be /dev/fd/3, not
e.g. $PWD/script.sh. Try the source code I had pasted in my mail, you'll
see.

> > > 3) How come other architectures don't have this problem, and only Hurd
> > > has? 
> > 
> > Because Hurd is not Unix.
> 
> Sorry, Samuel, I don't consider the above an answer.

I'm sorry, but that's the most reasonable one with little time spent on
it. execv shares about zero code between linux and hurd, so there's no
way to can expect any similarity in bugs.

> Obviously other architectures have been able to solve this problem
> without introducing a new RPC.

Yes, because in a monolithic kernel, you can do anything you want.

> What makes it so hard on GNU/Hurd, is it the microkernel
> architeture?

Yes. See Emilio's mails: the problem is that while eglibc knows what to
put in $0, the part in the exec server doesn't. His patch is all about
simply transmitting the information from glibc to exec, so that the
latter can pass it in $0, and not just /dev/fd/3.

> And how has Apple solved such problems in their mix of monolitic/micro
> architecture?

Because their micro architecture has almost nothing micro, there's not
such separation as in GNU/Hurd.

Sorry for being harsh here, but it'd be good if you could at some point
manage to read e.g. the glibc source code yourself and find out things
yourself, because the more you ask me things, the less I have time to
spend on other things, such as the dhcp patch which I still haven't
found any time to work on.

Samuel