[Mesa-dev] Mismatch between Mesas dispatch table and the one used by the X server

[Ian Romanick]

On 03/20/2013 02:43 PM, Stefan Brüns wrote:
> On Tuesday 12 March 2013 09:25:07 Ian Romanick wrote:
>> On 03/10/2013 11:24 AM, Stefan Brüns wrote:
>>> Hi everyone,
>>>
>>> I have run into a problem leading to a crashing X server for a bunch of
>>> indirect GLX calls.
>>>
>>> This problem affects any OpenGL clients using indirect rendering and
>>> calling functions which are outside the ABI. Problems range from
>>> malfunctioning to crashes.
>>>
>>> Problem analysis:
>>>
>>> The dispatcher functions in glx/indirect_dispatch.c demarshall the
>>> function
>>> arguments from the GLX wire protocol and then call the appropriate
>>> function of the GL library. Function calls are done using dispatch table
>>> with the help of the CALL_* helper macros defined in dispatch.h.
>>>
>>> Unfortunately there is a mismatch between the dispatch table expected by
>>> the xserver - which follows the layout e.g. found in glapitable.h - and
>>> the one provided by the GL library, e.g. Mesa.
>>
>> The dependency is the other way around.  The loader (either libGL on the
>> client or the GLX extension in the server) dictates the layout of the
>> dispatch table.  The GL driver is required to adapt to the layout
>> dictated by the loader.  That's the whole reason the remap table exists.
>>    The driver queries the loader to learn where functions are located in
>> the dispatch table.  It then stores the dispatch table locations at
>> (fixed) locations in the remap table.  So, the driver knows that glFoo
>> is at location 824 in the remap table, and that entry stores the
>> location of glFoo in the dispatch table.
>>
>> It sounds like something else is going wrong.
>
> Currently this obviously can not work.
>
> The remap table is only used when FEATURE_remap_table is defined, which for
> the X server is never true.
>
> Now, lets try defining FEATURE_remap_table for the xserver (which breaks OS X
> and windows builds of Mesa, but anyway ...)

Xserver has nothing to do with it.  The remap table is entirely in the 
driver (*_dri.so).  The xserver has no knowledge about the remap table 
whatsoever.  The xserver only knows about the dispatch table, and it 
dictates where things are in that table.

It's been a long time since I wrote this code, but I haven't been able 
to kill of all the memories of it yet. :)

> Even then, the lookup of indexes for the remap table is going wrong.
>
> The xserver uses the remap table slots defined in the dispatch.h exported from
> some past version of Mesa, i.e. "#define TexBufferARB_remap_index 174".
>
> Now the remap table is populated from _mesa_init_remap_table in
> mesa/main/remap.c, which calls:
> _mesa_do_init_remap_table(_mesa_function_pool,
> driDispatchRemapTable_size, MESA_remap_table_functions);
>
> Now lets have a look a look into MESA_remap_table_functions[174], which should
> have the entry for TexBufferARB, and yes, its there, so everything fine!
>
> But wait, do another test - ClientWaitSync, slot 178 in remap table, at least
> if you ask the x server, but slot 185 if you ask Mesa ...
>
> So obviously the remap table is filled with the wrong values.
>
> Regards, Stefan