[Glibc-bsd-devel] GNU/kFreeBSD status

[Nathan Hawkins]

On Mon, Jan 26, 2004 at 10:55:45AM +0100, Robert Millan wrote:
> On Sun, Jan 25, 2004 at 11:49:48AM -0500, Nathan Hawkins wrote:
> > Hmm. You might want to verify the syscall number, and look at how it's
> > implemented in the native libc. brk always failing sounds suspiciously
> > like the wrong syscall, or an obsoleted one.
> 
> After a funny time debugging it, I came up with a test case that implements
> the kernel call in asm and still fails on gnu/kfreebsd (I'm attaching it).
> 
> It's obvious now that the error is in the parameter we've been passing to
> SYS_break. On Glibc, getting the break address from sbrk(0) or the internal
> symbol __curbrk is equivalent, since sbrk(0) reads it from __curbrk. The
> result is that __curbrk contains the wrong address. The bug we're looking for
> might be in the process initialisation routines.

That sounds reasonable.

> > Either at this point. Anything but dealing with /usr/ports. 
> > 
> > At this point, I'm seriously considering restarting my native libc port.
> > glibc still needs major work, and I need something stable that I can use
> > in production relatively soon.
> 
> Eek. If it's because of the resolver bug, why don't you fix it yourself? It's
> in my TODO anyway, but brk() has more priority currently.

Because I don't want to hack on glibc. I've messed with it, and I'd
prefer to leave it alone. The BSD libc is much easier to understand and
work on.

In any case, there are plenty of other problems. The big issue for me,
is that glibc on FreeBSD is really very much alpha quality, maybe early
stages beta. It isn't usable for production systems, and won't be for
quite a while - at the least because it will take a long time to
discover, much less fix, all the bugs.

> > > Newer versions of gnu ld (from binutils) refuse to link when ld.so
> > > is an executable instead of a shared library. Therefore we should
> > > discuss this with both Glibc and binutils maintainers to find out
> > > which out of gnu ld.so.1 or gnu ld is in fault.
> > 
> > An alternative might be to link two copies of ld.so, and use the normal
> > one for everything but ldd.
> 
> We do something like that already, see the ldso-hack package.

Hmm. Well, if it's ok with the glibc maintainers, I'd probably just
have glibc package include two copies of ld.so. Consider that a feature
specific to freebsd-i386.

	---Nathan