This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

__builtin_frame_address vs %esp in pt-machine.h

From: Roland McGrath <roland at redhat dot com>
To: Ulrich Drepper <drepper at redhat dot com>
Cc: GNU libc hackers <libc-hacker at sources dot redhat dot com>
Date: Sat, 5 Oct 2002 14:55:20 -0700
Subject: __builtin_frame_address vs %esp in pt-machine.h

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.

Follow-Ups:
- Re: __builtin_frame_address vs %esp in pt-machine.h
  - From: Ulrich Drepper

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]