Re: nss and pthreads and wine, oh my!

On Wednesday 10 December 2003 11:08 am, Jacques A. Vidrine wrote:
> But, maybe I'm just misunderstanding you.  I believe the thread
> functions are `stubbed out' in the non-thread case?

After more investigation, wine seems to be a special case.  It's 'sort-of' 
threaded.  It links against libc.so.5, but provides its own set of pthread 
functions that it uses internally (and are defined as strong aliases).  The 
stub functions are getting called, but they're not pointing at stub_zero 
anymore.  Actually, I can't figure out WHERE they're going...

Here's a dump of the thread jump table right as wine starts up:
(gdb) print __thr_jtable
$1 = {{0x5c09d683 <stub_zero>, 0x5c09d683 <stub_zero>}, {
    0x5c09d683 <stub_zero>, 0x5c09d683 <stub_zero>}, {0x5c09d683 <stub_zero>, 
    0x5c09d683 <stub_zero>}, {0x5c09d683 <stub_zero>, 0x5c09d683 <stub_zero>}, 
  {0x5c09d683 <stub_zero>, 0x5c09d683 <stub_zero>}, {0x5c09d68d <stub_null>, 
    0x5c09d68d <stub_null>}, {0x5c09d683 <stub_zero>, 0x5c09d683 <stub_zero>}, 
  {0x5c09d683 <stub_zero>, 0x5c09d683 <stub_zero>}, {0x5c09d6ad <stub_main>, 
    0x5c09d6ad <stub_main>}, {0x5c09d683 <stub_zero>, 
    0x5c09d683 <stub_zero>} <repeats 16 times>, {0x5c09d697 <stub_self>, 
    0x5c09d697 <stub_self>}, {0x5c09d683 <stub_zero>, 0x5c09d683 <stub_zero>}, 
  {0x5c09d683 <stub_zero>, 0x5c09d683 <stub_zero>}}

Looks normal so far.  Again in the middle of nsdispatch (right before the 
crash)

(gdb) print __thr_jtable
$3 = {{0x5ce1b33c, 0x5ce1b33c}, {0x5ce1aa3c, 0x5ce1aa3c}, {0x5ce1a944, 
    0x5ce1a944}, {0x5ce1b15c, 0x5ce1b15c}, {0x3c002298 <__pthread_cond_wait>, 
    0x5ce1aaad}, {0x5ce0db53, 0x5ce0db53}, {0x5ce0d6a4, 0x5ce0d6a4}, {
    0x5ce0d7b6, 0x5ce0d7b6}, {0x5ce18c4c, 0x5ce18c4c}, {0x5ce13aa8, 
    0x5ce13aa8}, {0x5ce138aa, 0x5ce138aa}, {0x3c002003 <__pthread_mutex_lock>, 
    0x5ce1479f}, {0x3c002029 <__pthread_mutex_trylock>, 0x5ce140cd}, {
    0x5ce1480a, 0x5ce1480a}, {0x5ce18a70, 0x5ce18a70}, {0x5ce18be4, 
    0x5ce18be4}, {0x5ce18b4b, 0x5ce18b4b}, {0x5ce134d8, 0x5ce134d8}, {
    0x5ce119c8, 0x5ce119c8}, {0x5ce11a3c, 0x5ce11a3c}, {0x5ce11b42, 
    0x5ce11b42}, {0x5ce11c33, 0x5ce11c33}, {0x5ce11cf8, 0x5ce11cf8}, {
    0x5ce11d9d, 0x5ce11d9d}, {0x5ce11e8f, 0x5ce11e8f}, {0x5ce11240, 
    0x5ce11240}, {0x5ce0da36, 0x5ce0da36}, {0x5ce0df30, 0x5ce0df30}}

I know these offsets are meaningless, even between multiple sessions on my own 
machine, but:

the 0x3c000000 functions are all part of wine's internal pthreads functions.  
That makes sense to me; they should override the stub functions in libc.  But 
I haven't a clue what's at 0x5ce00000.  Some shared library is getting loaded 
that has yet ANOTHER set of pthread functions.  I don't think it's libc_r -- 
I have that built with debug symbols so they should be identified in that 
case...

This is getting very complicated very fast.  Is there any way in gdb to find 
out which shared libraries are loaded and what base address they got mapped 
to?

Craig