[Top][All Lists]

[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: Sun, 23 May 2021 19:40:25 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 5/23/21 5:14 AM, Bruno Haible wrote:

I agree that these handlers are _usually_ small and don't have nested
functions. But a restriction is a restriction, and should be documented
as such. Find attached a proposed patch.

Thanks, that looks good except please change "create nested functions" to "create and then use nested functions", as it's OK to for a stack-overflow handler to create a nested function without using it.

Should a similar restriction be documented for libsigsegv, or is that library immune to this problem?

No, "gcc -fno-trampolines" doesn't get rid of the need to have an executable
stack. In the attached sample code gcc-closure.c, GCC 11.1 produces identical
code with "gcc -fno-trampolines" than with "gcc -ftrampolines".

Ouch, I didn't know that -fno-trampolines doesn't work for C or C++. The GCC manual implies otherwise. I filed a GCC doc bug report here:


I think we should get clarity first, regarding which
of the three approaches (static allocation, malloc, alloca) is preferrable.
I'll try to write documentation for it.

If I understand you correctly, all three approaches will work if stack-overflow handlers don't create and use nested functions, and alloca will work even if nested functions are used.

The main problem is: what size to allocate for the alternate stack? If I understand recent glibc discussions correctly, the "right" size might vary dynamically even within a thread, which makes any approach problematic if it doesn't want to allocate an alternate stack large enough to be future-proof. This is where I hope Florian Weimer's proposed approach will rescue us somehow.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]