On 10/11/20 3:08 PM, Bruno Haible wrote:
But do you have an overview which targets are meant in the doc?
Unfortunately not. I expect it'd have to be determined from the comments in GCC,
and it might also need info from various OSes and/or linkers.
Paul Eggert wrote:
> That being said, it does look like a reliability win if we start using
> -fstack-clash-protection on platforms like Fedora x86-64 that support it and
> do
> not enable it by default. Perhaps we should have a Gnulib or Autoconf macro
> that
> does that.
Yes, such a macro w
On 10/10/20 2:49 PM, Bruno Haible wrote:
gcc -fstack-clash-protection -m32 -O2 stackish.c fixes this issue.
Yes. However, the GCC manual says this about -fstack-clash-protection:
Most targets do not fully support stack clash protection. However,
on those targets '-fstack-clash-prote
Paul Eggert wrote:
> > On Linux, the kernel allows the stack to grow by any amount, if it does not
> > become closer than 1 MB to another VMA and does not violate the set limits.
> > See linux/mm/mmap.c:expand_downwards and linux/mm/mmap.c:acct_stack_growth.
> > Therefore on Linux, there is no need
On 10/10/20 5:08 AM, Bruno Haible wrote:
On Linux, the kernel allows the stack to grow by any amount, if it does not
become closer than 1 MB to another VMA and does not violate the set limits.
See linux/mm/mmap.c:expand_downwards and linux/mm/mmap.c:acct_stack_growth.
Therefore on Linux, there is
ther VMA and does not violate the set limits.
See linux/mm/mmap.c:expand_downwards and linux/mm/mmap.c:acct_stack_growth.
Therefore on Linux, there is no need for a guard page and no need for
'gcc -fstack-clash-protection'.
In both cases, it "just works". What other features around stack b
On 9/22/20 5:58 PM, Bruno Haible wrote:
It sounds what you want is a function that returns the stack bounds, in such a
way that every recursion step in a recursive function call the code can ask
"am I close to the stack bound? do I need to stop recursing?"
That shouldn't be ne
rflow (as witness
> the name stackoverflow.com!) it is somewhat disturbing that there is still no
> reliable way in GNU/Linux to answer the simple question "Where's my stack?"
> or
> to detect and recover from stack overflow reliably. What's up with that?
It sounds what yo
bounds; Linux escapes the
problem by returning the alternate stack bounds (which _is_ a stack_t).
> Again, anyone know how to report something like that?
First, gather enough arguments that it is really a bug in Linux (which I
dispute). Then, write a kernel patch that fixes the bug, relative to
Eric Blake byu.net> writes:
> >
> > On the other hand, POSIX states for sigaction() that the handler's "third
> > argument can be cast to a pointer to an object of type ucontext_t to refer
to
> > the receiving thread’s context that was interrupted when the signal was
> > delivered."
> |
> |>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 6/6/2008 6:25 AM:
| According to Bruno Haible on 6/6/2008 5:29 AM:
| | The type of the third argument, according to POSIX, is 'void *ucp'.
| Why does
| | it have to be cast? Why is it not directly 'ucontext_t *ucp' (since,
|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 6/6/2008 5:29 AM:
| The type of the third argument, according to POSIX, is 'void *ucp'. Why does
| it have to be cast? Why is it not directly 'ucontext_t *ucp' (since, as you
| say, ucontext_t will be defined in )?
I thin
Eric Blake wrote:
> On the other hand, POSIX states for sigaction() that the handler's "third
> argument can be cast to a pointer to an object of type ucontext_t to refer to
> the receiving thread’s context that was interrupted when the signal was
> delivered."
The type of the third argument, ac
Bruno Haible clisp.org> writes:
>
> Eric Blake wrote:
> > user_context->uc_stack.ss_sp contains the location
> > of the currently running (alternate) stack, not the stack where the fault
> > occurred. ... find out where the _original_ stack ended
I'm not sure if it is a bug or intentional t
Eric Blake wrote:
> user_context->uc_stack.ss_sp contains the location
> of the currently running (alternate) stack, not the stack where the fault
> occurred. ... find out where the _original_ stack ended
> ...
> I haven't looked at how libsigsegv handles this situation
libsigsegv has a soluti
15 matches
Mail list logo
