Re: RFC: "Generic" gthread model

[Jonathan Larmour <jlarmour at redhat dot com>]

Loren James Rittle wrote:
> 
> OK, you basically sold me. ;-)  I think you need approval from someone
> with global write privs.  I am just a mere user of the gthr.h API in
> code I rewrote for libstdc++, not someone that can approve a change.

Fair enough, but all comments are of course welcome :).
 
> /* t.c */
> 
> #include <stdio.h>
> 
> #define STRING(x) STRINGX(x)
> #define STRINGX(x) #x
> 
> void foo (void) { printf (__FUNCTION__ " " STRING(UNIQ) "\n"); }
> 
> void UNIQ (void) { foo (); printf (__FUNCTION__ " " STRING(UNIQ) "\n"); }
> 
> /* main.c */
> 
> #include <stdio.h>
> 
> void foo (void);
> void t1 (void);
> void t2 (void);
> void t3 (void);
> void t4 (void);
> 
> int main (void)
> {
>   foo ();
>   t1 ();
>   t2 ();
>   t3 ();
>   t4 ();
>   return 0;
> }
> 
> gcc -DUNIQ\=t1 -fpic -shared -o libt1.so t.c
> gcc -DUNIQ\=t2 -fpic -shared -o libt2.so t.c
> gcc -DUNIQ\=t3 -c -o t3.o t.c
> gcc -DUNIQ\=t4 -c -o t4.o t.c
> ar r libt4.a t4.o
> ar r libt3.a t3.o
> gcc -lt1 -lt2  -L. -R. main.c -lt3 -lt4
> ./libt4.a(t4.o): In function `foo':
> t4.o(.text+0x0): multiple definition of `foo'
> ./libt3.a(t3.o)(.text+0x0): first defined here
> collect2: ld returned 1 exit status
> 
> Perhaps a contrived example...  But it actually shows a problem I
> didn't expect: namely, collision between static libraries...

However your example does not correspond to what would happen with libgcc.
Naturally you get errors because t2() pulls in libt2.so's definition of
foo(). However in the libgcc case, this could only apply if the user had
made a call that was in libgcc that was not in the replacement
implementation. That should not happen because there should not be any
functions that are not replaced.

Unless you are saying that they should be allowed to only override
portions. In which case, as I said in my last mail, I consciously decided
against this because I believe they should implement the full API or not at
all. They cannot tell which parts of the API are and aren't going to be
used and relied on between different versions of GCC, so I don't want to
offer them a false choice.

We could need to add weak functions in future if the gthread API was
extended further though, but I can't predict the future :).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine