[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11670

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2010-06-07 13:12 -------
See special_function_p, it will skip over __ prefix and then match sigsetjmp.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11670

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[christian dot eggers at kathrein dot de]

------- Additional Comments From christian dot eggers at kathrein dot de  2010-06-07 13:03 -------
(In reply to comment #4)
> GCC already knows that __sigsetjmp returns twice.
Are you sure?

# cd src/gcc-4.4.4
# find . | xargs grep __sigsetjmp
[some files under fixincludes]
<EOF>

I've no idea about GCC internals, but how does GCC know about the special
behaviour of __sigsetjmp()? Is this documented somewhere?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11670

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[schwab at linux-m68k dot org]

------- Additional Comments From schwab at linux-m68k dot org  2010-06-07 12:26 -------
Please report that as a compiler bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=11670

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[schwab at linux-m68k dot org]

------- Additional Comments From schwab at linux-m68k dot org  2010-06-07 12:20 -------
GCC already knows that __sigsetjmp returns twice.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11670

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[christian dot eggers at kathrein dot de]

------- Additional Comments From christian dot eggers at kathrein dot de  2010-06-07 12:05 -------
(In reply to comment #2)
> Which compiler are you using?  
I'm using gcc-4.4.4

> Since the variables are not modified between setjmp and longjmp they must
> retain their values even after setjmp returns the
> second time and the compiler is not allowed to reuse their stack location.  
> This looks like a compiler bug.
I think the compiler has no chance to detect that __sigsetjmp() may return a
second time (usual functions don't do that). I think that the "returns_twice"
attribute has to be added to the prototype of __sigsetjmp() in pthread.h.

The longjmp(3) manpage says that the values of automatic variables are ONLY
unspecified if they are changed between setjmp() and longjmp(). Maybe this
depends on the "returns_twice" attribute.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=11670

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[schwab at linux-m68k dot org]

------- Additional Comments From schwab at linux-m68k dot org  2010-06-07 08:40 -------
Which compiler are you using?  Since the variables are not modified between
setjmp and longjmp they must retain their values even after setjmp returns the
second time and the compiler is not allowed to reuse their stack location.  This
looks like a compiler bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=11670

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/11670] Variables defined in pthread_cleanup_push() macro may be optimised away which breaks __sigsetjmp

[ceggers at gmx dot de]

------- Additional Comments From ceggers at gmx dot de  2010-06-05 07:22 -------
Created an attachment (id=4828)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4828&action=view)
Patch for pthread_cleanup_push() and pthread_cleanup_pop()


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11670

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.