B
Borneq
Where I can find setjmp,longjmp, sigsetjmp implementation? In GCC source I
can't find.
can't find.
Użytkownik "Borneq said:Where I can find setjmp,longjmp, sigsetjmp implementation? In GCC source I
can't find.
Użytkownik "Borneq said:
Borneq said:Where I can find setjmp, longjmp, sigsetjmp implementation?
Uzytkownik "Noob said:
Borneq said:longjmp_unwind, __sigprocmask, __longjmp are in other library?
Uzytkownik "Noob said:1) tar xjf glibc-2.16.0.tar.bz2
2) grep -rn __longjmp glibc-2.16.0
e.g.
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i386/__longjmp.S
Noob said:1) tar xjf glibc-2.16.0.tar.bz2
2) grep -rn __longjmp glibc-2.16.0
e.g.
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i386/__longjmp.S
BartC said:Noob said:1) tar xjf glibc-2.16.0.tar.bz2
2) grep -rn __longjmp glibc-2.16.0
e.g.
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i386/__longjmp.S
This is not C. In that case why does it need to be that complicated? I
used to do this in just 3 instructions:
mov esp,[spsave]
mov ebp,[bpsave]
jmp [....]
It worked.
Doesn't the whole machine state have to be
saved/restored(registers/Fp/SSE/flags etc)?
No.
What if the calling function was using some regs for local vars etc ?!...
Nobody said:7.13.2.1p3:
All accessible objects have values as of the time longjmp was
called, except that the values of objects of automatic storage
duration that are local to the function containing the
invocation of the corresponding setjmp macro that do not have
volatile-qualified type and have been changed between the
setjmp invocation and longjmp call are indeterminate.
gcc will warn about such cases with e.g.:
warning: variable ‘foo’ might be clobbered by ‘longjmp’ or ‘vfork’
Typically, only the "essential" registers (program counter, stack pointer,
frame pointer) are preserved. Registers holding local variables or
intermediate results aren't required to be preserved (and usually aren't).
"Global" state isn't modified by longjmp and, AIUI, that includes the FP
environment (<fenv.h>).
s/No/Maybe/
7.13.2.1p3:
All accessible objects have values as of the time longjmp was
called, except that the values of objects of automatic storage
duration that are local to the function containing the
invocation of the corresponding setjmp macro that do not have
volatile-qualified type and have been changed between the
setjmp invocation and longjmp call are indeterminate.
gcc will warn about such cases with e.g.:
warning: variable ‘foo’ might be clobbered by ‘longjmp’ or ‘vfork’
Typically, only the "essential" registers (program counter, stack pointer,
frame pointer) are preserved. Registers holding local variables or
intermediate results aren't required to be preserved (and usually aren't).
"Global" state isn't modified by longjmp and, AIUI, that includes the FP
environment (<fenv.h>).
Johann Klammer said:BartC wrote:
This is not C. In that case why does it need to be that complicated? I
used to do this in just 3 instructions:
mov esp,[spsave]
mov ebp,[bpsave]
jmp [....]
It worked.
Doesn't the whole machine state have to be
saved/restored(registers/Fp/SSE/flags etc)? What if the calling function
was using some regs for local vars etc ?!...
Yes, I meant the latter... to the compiler the setjmp is just a functionIf you mean the function executing the 'setjmp': how many of those things
you mentioned are actually saved and restored during a routine function
call? Possibly the registers if in the middle of a calculation. But when
you
come back after longjmp, you're no longer in the middle of that
calculation!
Anyway I knew exactly what was going on in my hardware, and presumably the
OP will know his.
Johann Klammer said:BartC wrote: [snip]If you mean the function executing the 'setjmp': how many of those
things you mentioned are actually saved and restored during a
routine function call?
Possibly the registers if in the middle of a calculation. But when
you come back after longjmp, you're no longer in the middle of that
calculation!
Yes, I meant the latter... to the compiler the setjmp is just a function
call, nothing else.
It has been some time since I read up on calling conventions,
but I believe that the compiler is _not_ required to save
and restore _all_ of the registers on entry/exit of every function
call...? How does the compiler know you're not in 'the middle' of a
calculation anymore. Are you in 'the middle' if you are using some local
further down again after the return from setjmp?
He might not know what his compiler does with it..(no one really does)
They do funny things for speed gain.
BartC wrote:
[snip]
If you mean the function executing the 'setjmp': how many of those thingsyou mentioned are actually saved and restored during a routine functioncall? Possibly the registers if in the middle of a calculation. But when
come back after longjmp, you're no longer in the middle of thatcalculation!
Yes, I meant the latter... to the compiler the setjmp is just a function
call, nothing else. It has been some time since I read up on calling
conventions, but I believe that the compiler is _not_ required to save
and restore _all_ of the registers on entry/exit of every function
call...? How does the compiler know you're not in 'the middle' of a
calculation anymore. Are you in 'the middle' if you are using some local
further down again after the return from setjmp?
luser- -droog said:But isn't setjmp() only allowed within a condition (if, switch, etc.)?
It's *not* just a function call.
Yes, I meant the latter... to the compiler the setjmp is just a function
call, nothing else.
7.13.2.1p3:
All accessible objects have values as of the time longjmp was
called, except that the values of objects of automatic storage
duration that are local to the function containing the
invocation of the corresponding setjmp macro that do not have
volatile-qualified type and have been changed between the
setjmp invocation and longjmp call are indeterminate.
Johann Klammer said:BartC wrote: [snip]If you mean the function executing the 'setjmp': how many of those
things you mentioned are actually saved and restored during a
routine function call?
Possibly the registers if in the middle of a calculation. But when
you come back after longjmp, you're no longer in the middle of that
calculation!Yes, I meant the latter... to the compiler the setjmp is just a function
call, nothing else.
Is that really true? Seems to me that compilers can optimize stdlib
functions anyway they want, and that might include special case for
setjmp if needed.
Register save convention is pretty much system (usually OS) dependent.
Seems to me that setjmp() has to follow the system convention.
[...]
Also, on some the caller saves registers that it needs saved, and
others the callee saves registers that it will change.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.