[Mesa-dev] [Bug 33440] _gl_DispatchTSD in glapi_x86_64.S has incorrect relocation type

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=33440

Dimitry Andric <dimitry at andric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #42416|0                           |1
        is obsolete|                            |

--- Comment #4 from Dimitry Andric <dimitry at andric.com> 2011-01-27 13:07:18 PST ---
Created an attachment (id=42610)
 View: https://bugs.freedesktop.org/attachment.cgi?id=42610
 Review: https://bugs.freedesktop.org/review?bug=33440&attachment=42610

Change relocation type of _gl_DispatchTSD to GOTPCREL, take 2

Okay, I think I have now determined the proper way to solve this issue.
I should have examined my own gcc example more closely... :)

When Mesa is using pthreads, _gl_DispatchTSD is actually an instance of
the following struct:

struct u_tsd {
   pthread_key_t key;
   int initMagic;
};

The purpose of _x86_64_get_dispatch is to get the pthread-specific data
associated with the key (normally a struct mapi_table pointer).  In C
this would be:

void *_x86_64_get_dispatch(void)
{
   return pthread_getspecific(_gl_DispatchTSD.key);
}

which, using -fPIC, gets compiled by gcc to:

_x86_64_get_dispatch:
    movq    _gl_DispatchTSD at GOTPCREL(%rip), %rax
    movl    (%rax), %edi
    jmp    pthread_getspecific at PLT

E.g. the _gl_DispatchTSD at GOTPCREL(%rip) reference gives a pointer to the
start of the struct, which gets stored in %rax.  Then, the pointer is
dereferenced to get the first member of the struct: an unsigned int on
Linux, even on x86-64 (on FreeBSD, it's a regular int).  It is stored in
%edi, to serve as first parameter to pthread_getspecific(), which is
tail-called.

So please try this revised patch, which I have actually tested to run
properly on Linux.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.