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

Ilia Mirkin imirkin at alum.mit.edu
Sat Aug 29 18:57:49 PDT 2015

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.

I had actually assumed that this was more about rtasm stuff, but I
guess that's all separate.


More information about the mesa-dev mailing list