Re: [PATCH 2/3] MIPS: Preliminary vdso.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.
[Linux MIPS Home] [LKML Archive] [Linux ARM] [Linux] [Git] [Photo] [Yosemite News] [Linux SCSI] [Linux Hams]