Re: [Fwd: Debugging execve problems]

[Samuel Thibault]

Svante Signell, le Sat 07 Jan 2012 20:05:45 +0100, a écrit :
> On Sat, 2012-01-07 at 18:48 +0100, Samuel Thibault wrote:
> > 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 :
> ...
> > 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.
> 
> I ran the code you posted (an on the ML) on GNU/Linux, and will do the
> same for GNU/Hurd! It still does not explain how having . in $PATH
> solves the problem.

It solves because in that case exec finds it in PATH.

> > 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, 
> 
> Only reading the glibc source code would take ages for me to even come
> above the water level.

Really?  Did you just try?  There are some oddities and execv is not
particularly easy, but the basic principles should be understandable.

execv is defined only in posix/execv.c, which calls __execve, which is
defined only in both posix/execve.c and sysdeps/mach/hurd/execve.c,
which calls _hurd_exec, defined in hurd/hurdexec.c, which does a
lot of stuff.  The important thing to notice there is the call to
__file_exec(), which is an RPC to the exec server. And that's from where
the exec server doesn't know the actual path to the binary. Again, part
of this is described in Emilio's mails.

> Is there some description of the gnumach/hurd parts available?

No.

> > 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.
> 
> I could do that if you agree that we go back the the get_hw_address
> patch I first submitted is a better way to resolve the upstream doubts
> than your updated  version.

Problem is that if I proposed something else, it's most probably because
I believed that it was better, and more acceptable for upstream.

Samuel