This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


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

[Bug libc/16629] [aarch64] setcontext clobbers alternate signal stack


https://sourceware.org/bugzilla/show_bug.cgi?id=16629

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  7c6776620db8e48fca492dbcac88d1c0f239dcde (commit)
       via  e04a4e9d2e639a7770e1c0d24ecbcf92abf6bba8 (commit)
       via  37d350073888887637aa67dddf988d9c4b226032 (commit)
      from  423a7160af7fcffc61aac5e2e36d0b6b5b083214 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7c6776620db8e48fca492dbcac88d1c0f239dcde

commit 7c6776620db8e48fca492dbcac88d1c0f239dcde
Author: Will Newton <will.newton@linaro.org>
Date:   Thu Mar 13 09:45:29 2014 +0000

    manual/setjmp.texi: Clarify setcontext and signal handlers text

    Calling setcontext from a signal handler can be done safely so
    it is sufficient to note that it is not recommended.

    Also mention in setcontext documentation that the behaviour of
    setcontext when restoring a context created by a call to a signal
    handler is unspecified.

    2014-04-17  Will Newton  <will.newton@linaro.org>

        * manual/setjmp.texi (System V contexts): Add note that
        calling setcontext on a context created by a call to a
        signal handler is undefined.  Update text to note that
        setcontext from a signal handler is possible but not
        recommended.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e04a4e9d2e639a7770e1c0d24ecbcf92abf6bba8

commit e04a4e9d2e639a7770e1c0d24ecbcf92abf6bba8
Author: Will Newton <will.newton@linaro.org>
Date:   Tue Feb 25 14:29:32 2014 +0000

    stdlib/tst-setcontext.c: Check for clobbering of signal stack

    On aarch64 calling swapcontext clobbers the state of the signal
    stack (BZ #16629). Check that the address and size of the signal
    stack before and after the call to swapcontext remains the same.

    ChangeLog:

    2014-04-17  Will Newton  <will.newton@linaro.org>

        [BZ #16629]
        * stdlib/tst-setcontext.c: Include signal.h.
        (main): Check that the signal stack before and
        after swapcontext is the same.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=37d350073888887637aa67dddf988d9c4b226032

commit 37d350073888887637aa67dddf988d9c4b226032
Author: Will Newton <will.newton@linaro.org>
Date:   Wed Mar 12 16:14:51 2014 +0000

    aarch64: Re-implement setcontext without rt_sigreturn syscall

    The current implementation of setcontext uses rt_sigreturn to restore
    the contents of registers. This contrasts with the way most other
    architectures implement setcontext:

      powerpc64, mips, tile:

      Call rt_sigreturn if context was created by a call to a signal handler,
      otherwise restore in user code.

      powerpc32:

      Call swapcontext system call and don't call sigreturn or rt_sigreturn.

      x86_64, sparc, hppa, sh, ia64, m68k, s390, arm:

      Only support restoring "synchronous" contexts, that is contexts
      created by getcontext, and restoring in user code and don't call
      sigreturn or rt_sigreturn.

      alpha:

      Call sigreturn (but not rt_sigreturn) in all cases to do the restore.

    The text of the setcontext manpage suggests that the requirement to be
    able to restore a signal handler created context has been dropped from
    SUSv2:

      If  the context was obtained by a call to a signal handler, then old
      standard text says that "program execution continues with the program
      instruction following the instruction interrupted by the signal".
      However, this sentence was removed in SUSv2, and the present verdict
      is "the result is unspecified".

    Implementing setcontext by calling rt_sigreturn unconditionally causes
    problems when used with sigaltstack as in BZ #16629. On this basis it
    seems that aarch64 is broken and that new ports should only support
    restoring contexts created with getcontext and do not need to call
    rt_sigreturn at all.

    This patch re-implements the aarch64 setcontext function to restore
    the context in user code in a similar manner to x86_64 and other ports.

    ChangeLog:

    2014-04-17  Will Newton  <will.newton@linaro.org>

        [BZ #16629]
        * sysdeps/unix/sysv/linux/aarch64/setcontext.S (__setcontext):
        Re-implement to restore registers in user code and avoid
        rt_sigreturn system call.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                    |   17 +++
 NEWS                                         |   10 +-
 manual/setjmp.texi                           |   19 ++--
 stdlib/tst-setcontext.c                      |   21 ++++
 sysdeps/unix/sysv/linux/aarch64/setcontext.S |  150 ++++++++++++++++----------
 5 files changed, 149 insertions(+), 68 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


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