[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: determining the stack bounds
From: |
Bruno Haible |
Subject: |
Re: determining the stack bounds |
Date: |
Fri, 6 Jun 2008 01:56:18 +0200 |
User-agent: |
KMail/1.5.4 |
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 solution that works for most platforms, distributed over
several files:
File platforms uses
stackvma-linux.c Linux /proc/self/maps, mincore()
stackvma-freebsd.c FreeBSD /proc/curproc/map, mincore()
stackvma-mincore.c OpenBSD, NetBSD mincore()
stackvma-mach.c MacOS X vm_region()
stackvma-procfs.c IRIX, OSF/1, Solaris ioctl(PIOCMAP)
stackvma-beos.c BeOS get_next_area_info()
Would help to move this code to gnulib? Are there other uses of the stack VMA?
(Conservative garbage-collectors and Scheme interpreters only need to know
the current stack pointer and the stack top, AFAIK, not the stack bottom.)
Bruno
- c-stack vs. older platforms, Eric Blake, 2008/06/05
- Re: c-stack vs. older platforms, Paul Eggert, 2008/06/05
- Re: c-stack vs. older platforms, Bruno Haible, 2008/06/05
- Re: c-stack vs. older platforms, Eric Blake, 2008/06/05
- Re: c-stack vs. older platforms, Eric Blake, 2008/06/05
- Re: determining the stack bounds,
Bruno Haible <=
- Re: determining the stack bounds, Eric Blake, 2008/06/05
- Re: determining the stack bounds, Bruno Haible, 2008/06/06
- Re: determining the stack bounds, Eric Blake, 2008/06/06
- Re: determining the stack bounds, Eric Blake, 2008/06/06
- Re: determining the stack bounds, Eric Blake, 2008/06/06
- Re: determining the stack bounds, Bruno Haible, 2008/06/06
- Re: c-stack vs. older platforms, Eric Blake, 2008/06/06