On 02/23/2010 12:40 PM, Manuel Lauss wrote:
Hi David,
On Fri, Feb 19, 2010 at 1:13 AM, David Daney<ddaney@xxxxxxxxxxxxxxxxxx> wrote:
This is a preliminary patch to add a vdso to all user processes.
Still missing are ELF headers and .eh_frame information. But it is
enough to allow us to move signal trampolines off of the stack. Note
that emulation of branch delay slots in the FPU emulator still
requires the stack.
We allocate a single page (the vdso) and write all possible signal
trampolines into it. The stack is moved down by one page and the vdso
is mapped into this space.
Is there anything special required (i.e. special glibc, ..) to make use of these
fine patches?
No. Quite the opposite really, they are designed for the most part to
be transparent to userspace.
There are a couple of changes that shouldn't break anything serious:
1) The process' VMA will have a [vdso] region at the highest possible
address (above the stack). Most code will not care about this. However
if you mprotect(PROT_WRITE) the region and then clobber it or munmap it,
you will likely lose the ability to return from signal handlers. It is
copy-on-write, so this will not affect other processes.
2) The libgcc built by some older versions of GCC will not be able throw
exceptions across a signal frame. This is mostly a problem if you are
using libgcj (the GCC java runtime). Note however that the faulty
versions of libgcc would also fail on kernels that need
ICACHE_REFILLS_WORKAROUND_WAR (SGI O2). Most code doesn't try to throw
exceptions across signal frames, so it would be unaffected. Also note
that really old versions of libgcc don't support this trans-signal-frame
throwing at all.
3) GDB will not show a valid backtrace from a signal handler. I have
submitted a gdb patch, but it has not been accepted yet.
David Daney
