Re: [PATCH 2/3] MIPS: Preliminary vdso.

[David Daney <ddaney@caviumnetworks.com>]

On 02/23/2010 12:40 PM, Manuel Lauss wrote:
> Hi David,
>
> On Fri, Feb 19, 2010 at 1:13 AM, David Daney<ddaney@caviumnetworks.com>  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