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

[David Daney <ddaney@avtrex.com>]

Thiemo Seufer wrote:
> Brian Foster wrote:
> [snip]
>   
>>  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)
>>  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.
>
>
> Thiemo
>
>