This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: longjmp handling vs. glibc LD_POINTER_GUARD problems
- From: David Miller <davem at davemloft dot net>
- To: uweigand at de dot ibm dot com
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 14 May 2008 14:26:58 -0700 (PDT)
- Subject: Re: longjmp handling vs. glibc LD_POINTER_GUARD problems
- References: <200805141800.m4EI0IHe006471@d12av02.megacenter.de.ibm.com>
From: "Ulrich Weigand" <uweigand@de.ibm.com>
Date: Wed, 14 May 2008 20:00:18 +0200 (CEST)
> To implement implement get_longjmp_target I'd have to retrieve
> that guard value and demangle the pointers. This is of course
> possible in principle -- but this assumes that the details of
> where to find the guard value (typically somewhere in the
> thread control block header) remain fixed across glibc versions.
> I'm not sure we can actually rely on that. I couldn't find any
> exported glibc mechanism to retrieve this value in a supported
> way either ...
I think you can treat this the same way we treat the signal frame
layout. It's something undocumented but effectively fixed in stone.
If glibc ever changed the offset within the thread struct for this
cookie, so many binaries would break. So it is very likely the value
will stay the same for the forseeable future.
Thanks for pointing out this issue, I think sparc has the same
problem and thus needs the same longjmp hooks.