Re: [libc-alpha] linuxthreads bug in 2.2.4 under ppc linux

[Kevin B. Hendricks <kevin dot hendricks at sympatico dot ca>]

Hi,

I think this is optimization related (but I am still not sure).

Simply adding the one line:
     if (p_node == (struct wait_node *) 0) MSG("huh %p\n",&lock);

in spinlock.c in __pthread_alt_unlock() as shown below is enough to make 
things work (and this if is never taken).


    READ_MEMORY_BARRIER(); /* Prevent access to stale data through p_node 
*/

    while (p_node != (struct wait_node *) 1) {
      int prio;

      if (p_node == (struct wait_node *) 0) MSG("huh %p\n",&lock);


The question here is why does accessing p_node in this way make such a big 
difference to the compiler.

Any ideas here would be greatly appreciated, otherwise I am stuck.

Kevin



On December 8, 2001 08:15, Franz Sirl wrote:
> On Sunday 09 December 2001 01:59, Kevin B. Hendricks wrote:
> > Hi Franz,
> >
> > Okay, I am down to just rebuilding libpthread.so.
> >
> > If I compile linuxthreads with -O1 or -O2 I can not make it fail.
> >
> > If I compile linuxthreads with -O3 it fails in exactly the place I
> > described earlier.
> >
> > So the question is:
> >
> > Is this a ppc linux specific gcc compiler issue at -O3
> > with something being rescheduled that should not be?
> >
> > or
> >
> > Is the bug in glibc-2.2.4, and the change in optimization just changes
> > the timing to avoid or create the problem?
> >
> > I am going to diff the objdump from lipthread.so with -O2 and -O3 in
> > pthread_alt_lock and pthread_alt_unlock to see is anything jumps out
> > at me.
> >
> > I will let you know what if anything I find.
> >
> > It is nice to know that just lowering the optimization level to -O2
> > from -O3 for just linuxthreads seems to workaround the issue.
>
> Yeah, that's quite nice. I'm happy to switch back glibc to -O2
> compilation (-O3 isn't a big win anyway in glibc), unless you can show
> there is an underlying problem in glibc's thread code.
>
> Franz.