__builtin_frame_address vs %esp in pt-machine.h

__builtin_frame_address vs %esp in pt-machine.h

[Roland McGrath]

What was the reason for this change in linuxthreads?

     2001-04-12  Ulrich Drepper  <drepper@redhat.com>

	     * sysdeps/i386/Makefile: Make sure gcc uses a frame pointer for
	     all the files which use CURRENT_STACK_FRAME.
	     * sysdeps/i386/pt-machine.h (CURRENT_STACK_FRAME): Define using
	     __builtin_frame_address.
	     * sysdeps/i386/i686/pt-machine.h: Likewise.

The -fomit-frame-pointer build is broken for !FLOATING_STACKS because we
failed to keep the sysdeps/i386/Makefile up to date with every source file
that uses THREAD_*MEM (probably my fault).  The plan of adding all such
files to sysdeps/i386/Makefile seems very error prone (cf the current
error) and definitely ugly.  It would be safest to apply it to all the
linuxthreads source files.  

But I don't see why we don't just use the definition that works with or
without -fomit-frame-pointer.  I don't get any compilation errors from
reverting this change.  So I wonder what motivated it.  Going back to using
%esp in a global register variable seems like the best way to fix the
current problems to me.

Re: __builtin_frame_address vs %esp in pt-machine.h

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:
> What was the reason for this change in linuxthreads?
> 
>      2001-04-12  Ulrich Drepper  <drepper@redhat.com>
> 
> 	     * sysdeps/i386/Makefile: Make sure gcc uses a frame pointer for
> 	     all the files which use CURRENT_STACK_FRAME.
> 	     * sysdeps/i386/pt-machine.h (CURRENT_STACK_FRAME): Define using
> 	     __builtin_frame_address.
> 	     * sysdeps/i386/i686/pt-machine.h: Likewise.
> 
> The -fomit-frame-pointer build is broken for !FLOATING_STACKS because we
> failed to keep the sysdeps/i386/Makefile up to date with every source file
> that uses THREAD_*MEM (probably my fault). 

The problem is the ptlongjmp.c code.  For its use of CURRENT_STACK_FRAME
the value must be as accurate as possible since otherwise the detection
of frames which have to be handled might be wrong.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9n2JS2ijCOnn/RHQRAt2OAKCEdBga2IxMC/OtPCp2tQMKGWX+aQCfabYC
6c2IjgwOL7L+AI185XQGefQ=
=FjmT
-----END PGP SIGNATURE-----

Re: __builtin_frame_address vs %esp in pt-machine.h

[Roland McGrath]

> The problem is the ptlongjmp.c code.  For its use of CURRENT_STACK_FRAME
> the value must be as accurate as possible since otherwise the detection
> of frames which have to be handled might be wrong.

I don't understand this.  Its use is to check whether another frame's auto
variable address might be below (off the top) of the current stack.
Another frame's variable could never be between the cleanup function's %ebp
and %esp--that's its own frame.  So using %esp is fine there.

Re: __builtin_frame_address vs %esp in pt-machine.h

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:

> I don't understand this.  Its use is to check whether another frame's auto
> variable address might be below (off the top) of the current stack.


I've no time to think about the reason I had to make the change in the
moment.  But I added this code to fix a bug.  It is a necessary change.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9sGqf2ijCOnn/RHQRAoq1AJwMJjShrww39pgacpFPAW9f7y1x4gCgvwQl
bV2oSkGoy/ukqeezpXxE6fo=
=TXp9
-----END PGP SIGNATURE-----

Re: __builtin_frame_address vs %esp in pt-machine.h

[Roland McGrath]

> Roland McGrath wrote:
> > I don't understand this.  Its use is to check whether another frame's auto
> > variable address might be below (off the top) of the current stack.
> 
> I've no time to think about the reason I had to make the change in the
> moment.  But I added this code to fix a bug.  It is a necessary change.

Bah!  I searched all the logs and mailing list archives I could find and
didn't see anything that would have explained the problem, like a related
bug report around the time of the change.  This is why you write comments
in the code when there are nonobvious reasons for how it is!  

I still cannot imagine any reason why %esp would not be right for
ptlongjmp.c's use (and any other).