[Glibc-bsd-devel] GNU/kFreeBSD status

[Robert Millan]

--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sun, Jan 25, 2004 at 11:49:48AM -0500, Nathan Hawkins wrote:
> > linuxthreads is deprecated in upstream. Our final goal may be porting NPTL
> > or something else, I don't know, but eventualy linuxthreads would stop
> > working for us. For now, we'll use libpth with pthread emulation. That works
> > well enough to keep happy all pthread-hunger applications, untill we have
> > a definitive solution.
> 
> Good luck porting NPTL.

I'm not sure that NPTL is the best solution in the long-term. The short-term
is clear though.

> >   - sbrk() is implemented as a frontend to brk(), which is the broken one.
> >   - brk() always fails, no matter the parameter, and sets errno = ENOMEM
> >   - glibc/sysdeps/[...]/kfreebsd/i386/brk.S contradicts that, because it
> >     doesn't set errno and always returns 0 (xorl %eax, %eax\n ret)
> 
> 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.

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

My current Glibc sources (which build and such) are uploaded to gnuab. Just
fetch them and append your patch to debian/patches/kfreebsd-gnu.dpatch. When
you have a working patch send it to me and I'll add it to the package.

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

-- 
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T., Ainulindale (Silmarillion)

--qDbXVdCdHGoSgWSk
Content-Type: text/x-csrc; charset=us-ascii
Content-Disposition: attachment; filename="brk.c"

#include <stdio.h>
#include <unistd.h>

#ifdef __GLIBC__
extern int __curbrk;
#else
#define __curbrk sbrk(0)
#endif

int
my_syscall (int a, int b)
{
  asm ("pop %edx"); // ebp
  asm ("pop %ecx"); // ret
  asm ("pop %eax"); // 17
  asm ("push %ecx");
  asm ("int $0x80");
  asm ("push %ecx"); // ret
  asm ("push %edx"); // ebp
}

main ()
{
  int ret = my_syscall (17, __curbrk);
  printf ("cur = %d\nret = %d\n", __curbrk, ret);
  exit (0);
}

--qDbXVdCdHGoSgWSk--