This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 15/16] Avoid stack-protecting certain functions called from assembly.
- From: Andreas Schwab <schwab at suse dot de>
- To: Nix <nix at esperi dot org dot uk>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, <libc-alpha at sourceware dot org>, <nd at arm dot com>
- Date: Thu, 03 Mar 2016 17:55:38 +0100
- Subject: Re: [PATCH 15/16] Avoid stack-protecting certain functions called from assembly.
- Authentication-results: sourceware.org; auth=none
- References: <1456677695-29778-1-git-send-email-nix at esperi dot org dot uk> <1456677695-29778-16-git-send-email-nix at esperi dot org dot uk> <56D736BB dot 7000407 at arm dot com> <87lh5z4irf dot fsf at esperi dot org dot uk>
Nix <nix@esperi.org.uk> writes:
> I'm reasonably certain it has to do with pthread_cond_timedwait.S
> somehow setting up a stack frame and locals below it in a form which
> __pthread_mutex_{cond_lock_adjust,unlock_usercnt} then rely upon. I just
> don't understand how they could be doing that, since they seem to be
> calling the normal entry-point as usual. It's almost as if the call
> skips the usual stack-frame setup for the local variables in that
> function (including the canary), only I don't see how that could even be
> possible. But de-protecting them clearly works...
Have you tried stepping through the function to find the place where it
breaks?
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."