On Sat, 7 Apr 2012, David Schultz wrote:
On Fri, Mar 02, 2012, Tijl Coosemans wrote:
Hmm, old news. I think I already applied, but now notice some more details.
Thanks, that was quite informative. C11 does say something about the
FP env and signals now though:
``When the processing of the
On Fri, Mar 02, 2012, Tijl Coosemans wrote:
Thanks, that was quite informative. C11 does say something about the
FP env and signals now though:
``When the processing of the abstract machine is interrupted by receipt
of a signal, the values of objects that are neither lock-free atomic
On Sat, Mar 03, 2012 at 12:02:23PM +1100, Bruce Evans wrote:
On Fri, 2 Mar 2012, Tijl Coosemans wrote:
On Friday 02 March 2012 05:11:21 Bruce Evans wrote:
[... Lots about complications for longjmp() from a signal handler]
Thanks, that was quite informative. C11 does say something about the
On Sat, 3 Mar 2012, Konstantin Belousov wrote:
On Sat, Mar 03, 2012 at 12:02:23PM +1100, Bruce Evans wrote:
On Fri, 2 Mar 2012, Tijl Coosemans wrote:
So the interesting points for signal handlers move to:
- should signal handlers have to initialize their own state if they want
to use FP
On Saturday 03 March 2012 10:14:26 Konstantin Belousov wrote:
On Sat, Mar 03, 2012 at 12:02:23PM +1100, Bruce Evans wrote:
On Fri, 2 Mar 2012, Tijl Coosemans wrote:
On Friday 02 March 2012 05:11:21 Bruce Evans wrote:
[... Lots about complications for longjmp() from a signal handler]
On Sat, 3 Mar 2012, Tijl Coosemans wrote:
On Saturday 03 March 2012 10:14:26 Konstantin Belousov wrote:
longjmp() from a signal handler has very high chance of providing
wrong CPU state for anything except basic integer registers.
Not really, and return from a SIGFPE handler has a chance
On Friday 02 March 2012 05:11:21 Bruce Evans wrote:
On Thu, 1 Mar 2012, Tijl Coosemans wrote:
Also, from ISO C: All accessible objects have values, and all other
components of the abstract machine [249] have state, as of the time the
longjmp function was called
[249] This includes, but is
On Fri, 2 Mar 2012, Tijl Coosemans wrote:
On Friday 02 March 2012 05:11:21 Bruce Evans wrote:
[... Lots about complications for longjmp() from a signal handler]
Thanks, that was quite informative. C11 does say something about the
FP env and signals now though:
``When the processing of the
On Wednesday 29 February 2012 06:01:36 Bruce Evans wrote:
On Tue, 28 Feb 2012, Tijl Coosemans wrote:
Log:
Copy amd64 setjmp.h to x86 and replace amd64/i386/pc98 setjmp.h with stubs.
This may be correct (except for comment), but it is confusing.
Added:
head/sys/x86/include/setjmp.h
On Thu, 1 Mar 2012, Tijl Coosemans wrote:
On Wednesday 29 February 2012 06:01:36 Bruce Evans wrote:
...
Here is what current arches have in their machine/setjmp.h:
amd64, i386: not much
arm: has lots of comments and register offsets. These are defined as
_JB_REG_* so they aren't
Author: tijl
Date: Tue Feb 28 22:17:52 2012
New Revision: 232275
URL: http://svn.freebsd.org/changeset/base/232275
Log:
Copy amd64 setjmp.h to x86 and replace amd64/i386/pc98 setjmp.h with stubs.
Added:
head/sys/x86/include/setjmp.h
- copied unchanged from r232268,
On Tue, 28 Feb 2012, Tijl Coosemans wrote:
Log:
Copy amd64 setjmp.h to x86 and replace amd64/i386/pc98 setjmp.h with stubs.
This may be correct (except for comment), but it is confusing.
Added:
head/sys/x86/include/setjmp.h
- copied unchanged from r232268,
12 matches
Mail list logo