Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Sep 2002 08:18:47 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Daniel Eischen <eischen@pcnet1.pcnet.com>
Cc:        Julian Elischer <julian@elischer.org>, Edwin Culp <eculp@encontacto.net>, <current@FreeBSD.ORG>
Subject:   Re: slapd dumping core with today's current.
Message-ID:  <20020920080057.T3280-100000@gamplex.bde.org>
In-Reply-To: <Pine.GSO.4.10.10209190910090.13977-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Sep 2002, Daniel Eischen wrote:

> On Thu, 19 Sep 2002, Julian Elischer wrote:
> > On Thu, 19 Sep 2002, Daniel Eischen wrote:
> >
> > Ok so I reconnected the libc_r and fixed it to compile.
> >
> > I'm a littel uncomfortable because the new kernel behaviour means that
> > 4.x statically compiled threaded binaries will not work right because
> > we've changed the kernel ABI in an incompatible way..
> > We need to discuss this carefully when mini gets back to see if there is
> > a way out..
>
> I brought this up with bde before.  My suggestion was to create
> another sigreturn(), so we'd have osigreturn(), osigreturn2(),
> and [new] sigreturn().  He didn't like this.  I think we'd need
> another sendsig() too.
>
> When mini adds setcontext() as a system call, this can make
> sigreturn() obsolete.  The signal trampoline can call setcontext()
> instead of sigreturn() and sigreturn() can handle the old
> format...  We still need a different sendsig() though.

Unfortunately, we didn't get expansion of the i386 mcontext_t to make
room for SSE, into 4.0, and the problem has been mostly ignored since
then.  Looks like it is a large problem.

The things we might have to do to keep compatibile with old applications
are similar to the things that might be necessary for efficiency.
sendsig() and sigreturn() spend a lot of time copying out and in large
amounts of state that are never really used, especially by old
applications that cannot know about the new state.  Optimizations would
involve not copying it all, and compatibilty would also involve not
even leaving space for copying it all.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020920080057.T3280-100000>