[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34
From: |
Paul Eggert |
Subject: |
Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34 |
Date: |
Fri, 21 May 2021 15:49:26 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
On 5/18/21 10:34 AM, Bruno Haible wrote:
malloc'ed memory is not executable. But GCC's trampolines (used by nested
functions) require an executable stack. When an object file has such nested
functions, the toolchain arranges for the executable to ask the OS to
allocate an executable stack. But that only has an effect on the primary
stack of each thread. It does not have an effect on an alternate stack
(AFAIK).
That should be OK so long as stack-overflow handlers don't used nested
functions. Conversely, even programs that assume SIGSTKSZ is a constant
(and allocate fixed-size arrays on the stack or in static storage) will
have problems on such platforms, no? Stack and static storage won't be
executable any more than heap storage is.
I wouldn't mind, if it's done properly:
- The problem with non-executable malloc'ed memory would need to be
solved.
Or, we could just document that stack-overflow handers can't use
trampolines. That is a reasonable restriction for most apps, I would think.
- The declaration in sigsegv.h needs to stay, at least for the next
couple of years, because it is necessary for programs that use SIGSTKSZ
(such as GNU m4 and GNU clisp) to compile fine.
Why is it needed for GNU m4 and GNU clisp? I just looked at the latest
development source code for these programs, and neither mentions
SIGSTKSZ. GNU Emacs doesn't either (except in a configure.ac test that
does not assume SIGSTKSZ is a constant).
The only place I found that assumed that SIGSTKSZ is a constant, was in
Gnulib test cases. I removed that assumption by installing the first
attached patch.
And I propose the second attached patch to remove sigsegv.h's guarantee
that SIGSTKSZ is a constant, as glibc has gone a different way and it's
better if Gnulib tracks glibc.
0001-sigsegv-don-t-assume-SIGSTKSZ-is-a-constant.patch
Description: Text Data
0002-sigsegv-do-not-guarantee-SIGSTKSZ-is-constant.patch
Description: Text Data
- sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/16
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Paul Eggert, 2021/05/16
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/18
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34,
Paul Eggert <=
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/22
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Paul Eggert, 2021/05/23
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/23
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Paul Eggert, 2021/05/23
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/24
- Re: sigsegv.h interface, Bruno Haible, 2021/05/22
- Re: sigsegv.h interface, Paul Eggert, 2021/05/23