Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Jul 2007 10:53:34 -0700
From:      Alfred Perlstein <alfred@freebsd.org>
To:        Don Lewis <truckman@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, jhb@FreeBSD.org
Subject:   Re: cvs commit: src/sys/i386/i386 trap.c
Message-ID:  <20070730175334.GH92956@elvis.mu.org>
In-Reply-To: <200707300717.l6U7HcNC089641@gw.catspoiler.org>
References:  <200707270819.08197.jhb@freebsd.org> <200707300717.l6U7HcNC089641@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
* Don Lewis <truckman@FreeBSD.org> [070730 00:17] wrote:
> 
> After installing this patch, the bootstrap in the pm3-base port still
> fails.  I installed pm3-base from the 6-STABLE package, and it isn't
> able to compile any of the other ports.  I suspect the reason for the
> latter is that it is new enough to use sendsig() and not osendsig().
> This makes sense because osendsig is a COMPAT_43 function and the binary
> is a lot newer than that.
> 
> To preserve the "kludge" ABI as much as possible, I think it would be
> necessary to move the assignment to sc_err into the if-else block that
> checks to see if the signal handler was installed with the SA_SIGIFNO
> flag, and to make the same change in sendsig(), osendsig(), and
> freebsd4_sendsig().  This will break the wine port unless it uses
> SA_SIGINFO.
> 
> 
> As an alternative, I've got a set of patches to pm3-base to get it
> working on -CURRENT.  It wasn't too hard to fix the bootstrap to use the
> "undocumented 4th arg" to the signal handler that is mentioned in
> i386/include/sigframe.h.  The rest of the patches change the low-level
> Module-3 code to use sigaction() with the SA_SIGINFO flag instead of
> using a mixture of sigaction() (without SA_SIGINFO) and sigvec().
> I'll post the patches for testing once I've had a chance to clean them
> up some more.

This sounds really, really hackish.  I talked to Alan Cox about this
over the weekend and he said, if I have this right, that supposedly
a correct program actually does get the correct info on the stack
as an argument to their signal callback.  m3 should be fixed.

Either that, or we can rev the syscalls and introduce an actual
seperate field to the info that contains the fault address and
tell m3 to use that.

-- 
- Alfred Perlstein



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