This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: ARM backtrace() adjustment
On Thu, Jun 29, 2006 at 01:08:41PM +0200, Ladislav Michl wrote:
> do you mean this Mark's patch for 4.2?
> http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00357.html
>
> I used it for gcc-4.1.1 and it still doesn't work. What is recommended
> solution for gcc-4.1.1 users?
Well, this is just another example of 'check twice before posting'. Due
to clock skew on nfs server newly built glibc wasn't copied into
target's nfsroot... Works nicely now, thanks to everyone who made it
possible. Just for completeness here is rediffed patch against gcc-4.1.1
--- gcc-4.1.1/gcc/builtins.c.orig 2006-05-08 08:13:23.000000000 +0200
+++ gcc-4.1.1/gcc/builtins.c 2006-06-29 14:35:34.000000000 +0200
@@ -510,12 +510,16 @@
#else
rtx tem;
- /* For a zero count, we don't care what frame address we return, so frame
- pointer elimination is OK, and using the soft frame pointer is OK.
- For a non-zero count, we require a stable offset from the current frame
- pointer to the previous one, so we must use the hard frame pointer, and
+ /* For a zero count with __builtin_return_address, we don't care what
+ frame address we return, because target-specific definitions will
+ override us. Therefore frame pointer elimination is OK, and using
+ the soft frame pointer is OK.
+
+ For a non-zero count, or a zero count with __builtin_frame_address,
+ we require a stable offset from the current frame pointer to the
+ previous one, so we must use the hard frame pointer, and
we must disable frame pointer elimination. */
- if (count == 0)
+ if (count == 0 && fndecl_code == BUILT_IN_RETURN_ADDRESS)
tem = frame_pointer_rtx;
else
{
Best regards,
ladis