linux-mips
[Top] [All Lists]

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

To: Manuel Lauss <manuel.lauss@googlemail.com>
Subject: Re: [PATCH 2/3] MIPS: Preliminary vdso.
From: David Daney <ddaney@caviumnetworks.com>
Date: Tue, 23 Feb 2010 13:27:46 -0800
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <f861ec6f1002231240l40e1b07di6e751e40a2caa110@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1266538385-29088-1-git-send-email-ddaney@caviumnetworks.com> <1266538385-29088-3-git-send-email-ddaney@caviumnetworks.com> <f861ec6f1002231240l40e1b07di6e751e40a2caa110@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1
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


<Prev in Thread] Current Thread [Next in Thread>