On Sat, 2 Oct 1999, Thomas David Rivers wrote:
> >
> > > Just how much code will break?
> >
> > Boehm-gc, maybe. Modula-3, maybe. I can't remember whether it
> > catches both signals or just SIGBUS.
>
> I believe electric-fence would change as well.
It would change (by removing a freebsd-s
< said:
> More details on the POSIX signal numbers: SIGBUS is mainly for accesses
> beyond the end of mmap()ed objects. It's not clear what this means in
> an address space with multiple mmap()ed objects and/or non-mmap()ed
> objects.
`Beyond the end of the object' refers to the situation where
Bruce Evans wrote:
>
>> first implement the SA_SIGINFO support to the point where it could
>> accomplish that before changing SIGBUS to SIGSEGV. I think that makes
>> sense.
>
> SA_SIGINFO is implemented now.
Oh, when I checked it a couple of days ago it seemed like it wasn't
fully implemented
> >> > P.S. This also reminds me that FreeBSD is non-standard relative
> >> > to Linux and all of the major vender commercial Unices in that a disallowed
> >> > access, such as a write to a read-only region of memory, generates
> >> > a SIGBUS rather than a SIGSEGV.
> >>
> >> Yes, this even viol
On Sun, Oct 03, 1999 at 09:42:45AM +1000, Bruce Evans wrote:
>
> I think the POSIX way is to use an auxiliary error code in siginfo_t to
> distinguish the causes of the signal. This only works for SA_SIGINFO
> handlers. We do something similar using the signal code of 3-arg signal
> handlers.
>
>
> > Just how much code will break?
>
> Boehm-gc, maybe. Modula-3, maybe. I can't remember whether it
> catches both signals or just SIGBUS.
I believe electric-fence would change as well.
- Dave R. -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current
David O'Brien wrote:
>> > P.S. This also reminds me that FreeBSD is non-standard relative
>> > to Linux and all of the major vender commercial Unices in that a disallowed
>> > access, such as a write to a read-only region of memory, generates
>> > a SIGBUS rather than a SIGSEGV.
>>
>> Yes, this
On Sat, 2 Oct 1999, David O'Brien wrote:
> > > P.S. This also reminds me that FreeBSD is non-standard relative
> > > to Linux and all of the major vender commercial Unices in that a disallowed
> > > access, such as a write to a read-only region of memory, generates
> > > a SIGBUS rather than a
> > P.S. This also reminds me that FreeBSD is non-standard relative
> > to Linux and all of the major vender commercial Unices in that a disallowed
> > access, such as a write to a read-only region of memory, generates
> > a SIGBUS rather than a SIGSEGV.
>
> Yes, this even violates the 1996 POSI
> > Sigcontext will have to come back, since it is a standard BSD interface.
>
> I think so too. I bet there are several ports besides Modula-3 that
> use it. Probably boehm-gc does.
The JDK does as well, at least for the green-threads stuff.
Nate
To Unsubscribe: send mail to [EMAIL PROTE
Bruce Evans wrote:
> Sigcontext will have to come back, since it is a standard BSD interface.
I think so too. I bet there are several ports besides Modula-3 that
use it. Probably boehm-gc does.
> BTW, struct sigcontext seems to be documented only in sigreturn.2, and
> that documentation is mo
> I'm trying to digest the recent signal changes and get a handle on
> what I need to do to make Modula-3 work. There is code in the runtime
Sigcontext will have to come back, since it is a standard BSD interface.
Recent signal changes break even its source-level compatibility. Previous
signal
Alan Cox wrote:
> /* kludge to pass faulting virtual address to sendsig */
> frame->tf_err = eva;
>
> return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV);
> }
>
> Up until this point, frame->tf_err tells me details about the page
> fault, such as whether it was a
On Thu, Sep 30, 1999 at 01:40:22PM -0700, John Polstra wrote:
>
> Yep, I have fixed that in the PM3 release (which is the one that's
> actively maintained these days), but probably not in the SRC release
> on which our port is based. I have ports for PM3 in the wings,
> but I'm waiting for some
Alan Cox wrote:
>
> I guess this discussion means that the 4th argument is gone too...
>
Yes. ucontext_t (3rd argument) already contains that information and
siginfo_t *should* contain that information. There's not need for a 4th
argument anymore.
--
Marcel Moolenaarma
Alan Cox wrote:
> Actually, the last time I looked the Modula-3 run-time system
> determined the faulting address from the undocumented (except on
> SunOS 4) 4th argument that most BSD-derived systems passed to the
> signal handler.
Yep, I have fixed that in the PM3 release (which is the one tha
Marcel Moolenaar wrote:
>
> That's right, it's not implemented yet. The work-around is to use
> ucontext. uc_mcontext contains the trapframe which has tf_err
> (uc.uc_mcontext.mc_tf.tf_err).
Thanks.
> I haven't paid any attention to implement any of the fields in siginfo_t
> because that may on
Nate Williams wrote:
>
> > I'm trying to digest the recent signal changes and get a handle on
> > what I need to do to make Modula-3 work. There is code in the runtime
> > currently which catches SIGBUS and uses the sigcontext's "sc_err"
> > member to find out the faulting address. That should
Actually, the last time I looked the Modula-3 run-time system determined
the faulting address from the undocumented (except on SunOS 4) 4th argument
that most BSD-derived systems passed to the signal handler. There was
a time in fact when sc_err wasn't included in the sigcontext on FreeBSD
and th
> I'm trying to digest the recent signal changes and get a handle on
> what I need to do to make Modula-3 work. There is code in the runtime
> currently which catches SIGBUS and uses the sigcontext's "sc_err"
> member to find out the faulting address. That should be replaced
> by the siginfo_t's
I'm trying to digest the recent signal changes and get a handle on
what I need to do to make Modula-3 work. There is code in the runtime
currently which catches SIGBUS and uses the sigcontext's "sc_err"
member to find out the faulting address. That should be replaced
by the siginfo_t's "si_addr"
21 matches
Mail list logo
