[Mesa-dev] [PATCH] configure.ac: Add support to enable read-only text segment on x86.

[Matt Turner]

On Sat, Aug 29, 2015 at 6:57 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Sat, Aug 29, 2015 at 9:46 PM, Matt Turner <mattst88 at gmail.com> wrote:
>> On Sat, Aug 29, 2015 at 4:27 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> Why isn't this the default? IOW should this be incompatible with some
>>> other option and/or set based on some other option?
>>
>> Please don't top quote.
>
> I usually don't, but there wasn't a nice logical place for me to ask
> my question, top seemed as good as any.
>
>>
>> If I understand correctly, this option partially disables an
>> optimization in the dispatch table, but the options are still
>> distinct.
>>
>> My understanding is that with the x86 assembly dispatch
>> implementation, either (or both...?) of
>>
>> glapi_entrypoint.c:init_glapi_relocs()
>> entry_x86_tls.h:entry_patch_public()
>>
>> patch .text to contain the TLS pointer, so that the expensive "movl
>> %gs:0x0, %eax" doesn't happen on each GL function call. But that of
>> course requires a writable .text section, which is frowned upon.
>>
>> So --enable-glx-rts (I'd be happy to change the name to something less
>> cryptic) inhibits that, and instead does the expensive TLS look-up
>> (see src/mapi/glapi/gen/gl_x86_asm.py) on each GL call, but still uses
>> the assembly implementation.
>>
>> The assembly implementation is able to jump directly to the _mesa_*
>> function implementation (that is, not a call instruction that pushes
>> more stuff on the stack), so I think even with --enable-glx-rts, the
>> assembly implementation is still better than the C implementation.
>>
>> We'll see if idr reads his mail and can confirm my understanding.
>
> I see. Perhaps a small bit of this commentary can end up in the
> configure option help? i.e. that it allows .text to be read-only at
> some performance cost? Basically when I run ./configure --help, it's
> nice to know what the various options do without being deeply involved
> in the package's functionality. I think things like "read only text
> segment" make sense, but then the question becomes why it's not just
> always on -- mentioning that there's a small performance penalty would
> be nice.

Indeed, that's a good plan. Hopefully someone can confirm what I said
so I'm not just spreading rumours via ./configure --help :)