This is a discussion on Re: Serious compatibility breakage in -current. - FreeBSD ; Dag-Erling Smørgrav wrote: > "Carl Shapiro" writes: >> The switch from SIGBUS to SIGSEGV is well motivated. > > Is it? I see no mention of it in the commit log for the revision that > actually implemented the change. ...
Dag-Erling Smørgrav wrote:
> "Carl Shapiro"
>> The switch from SIGBUS to SIGSEGV is well motivated.
> Is it? I see no mention of it in the commit log for the revision that
> actually implemented the change. David argued on -CURRENT that it is
> more POSIXly correct, provided that he interpreted POSIX correctly; how
> do other operating systems behave in this case?
Apparently Linux uses SIGSEGV (there was an old commit by eivind to
i386/i386/trap.c that translated the signal for emulated binaries). So
in principle this might help some Linuxy code to not crash when compiled
on FreeBSD, although it is balanced by the code that now crashes when
compiled on FreeBSD 7.0 because it used to be correct until the signal
Unfortunately this is creating a bit of a compatibility nightmare,
because no matter what we do there are some applications that will not
run on 7.0 without changes. The best case scenario seems to be to
require new source code that expect SIGBUS to change to SIGSEGV (which
requires someone to identify and fix the code in ports; there are
certainly more of them), and try to automatically enable a compatibility
shim when running old binaries that reverts to the old signal. Kostik
is working on that approach. Probably the SIGSEGV change should be
clearly documented somewhere so that application writers will have a way
to learn about the change.
(We can't revert the kernel change and go back to sending SIGBUS because
it is far too late in the release cycle to identify and revert the ports
that already caught up to expecting SIGSEGV, so we'd be breaking a
different set of applications instead).
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"