[Top] [All Lists]

Re: Adding(?) XI support to MIPS-Linux?

To: Thiemo Seufer <>
Subject: Re: Adding(?) XI support to MIPS-Linux?
From: David Daney <>
Date: Tue, 10 Jun 2008 09:21:42 -0700
Cc: Brian Foster <>, "Kevin D. Kissell" <>, Andrew Dyer <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
User-agent: Thunderbird (X11/20080501)
Thiemo Seufer wrote:
Brian Foster wrote:
 2) Kevin D. Kissell wrote:
 2)[ ... ]
 2) > Well, strictly speaking, you wouldn't actually *need* to modify
 2) > binutils to make specially tagged binaries.  [ ... ]
 2) This exists already in ld's -z execstack/noexecstack feature.

Good point.  Thanks for the reminder.

 2) It is not used by default because too many things depend on executable
 2) stacks on MIPS.

Ah!  Can you be more specific please?  At the present time
I'm only aware of three situations where executable stacks
are magically used ("magic" meaning it's being done without
the programmer explicitly coding it):

  1. sigreturn.
  2. something to do with FPU emulation?
  3. pointer to a nested function (gcc extension).

Those, plus manually coded trampolines in e.g. foreign function
interfacing (which are typically hidden in some library). I don't
know if you can ignore that completely. :-)

The trampolines in libffi are user allocated, so there is a choice of where to place them. In libgcj (which uses the libffi trampolines) the trampolines are allocated on the heap and care is taken to set the execute permissions on the memory in question. Other users may have problems, but by now most code should work as XI support has been present on x86 for quite some time now.

As long as there is a mechanism to make user space stacks (and heap) executable, there should be no problem. People running code that requires it can switch off the XI support.

David Daney
And, significantly, I am do not know of any need for the
kernel-mode stacks to be executable.  Except, perhaps,
for case 3, the above are (should be?) user-land only.

AFAIK nested functions are frowned upon in kernelspace.


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