target/6249: Profiling breaks pthread code on Solaris 8

[lennox at cs dot columbia dot edu]

>Number:         6249
>Category:       target
>Synopsis:       Profiling breaks pthread code on Solaris 8
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 10 14:36:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        gcc-3.0.2
>Organization:
>Environment:
grandcentral $ uname -a
SunOS grandcentral.cs.columbia.edu 5.8 Generic_111850-02 sun4u sparc
You have mail in /var/mail//lennox
grandcentral $ gcc -v
Reading specs from /usr/local/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.0.2/specs
Configured with: /src/unpack/gnu/gcc-3.0.2/configure --prefix=/usr/local/gnu --with-gnu-as --with-gnu-ld --with-as=/usr/local/gnu/bin/as --with-ld=/usr/local/gnu/bin/ld
Thread model: posix
gcc version 3.0.2
>Description:
When I compile code that uses pthread_* functions on Solaris 8 with the -pg option, the pthread functions return -1 rather than do anything.

-1 is not a valid return value for pthread_*; they're specified as returning an errno.

This makes it quite difficult to profile pthread-using code.

This problem also causes profiled C++ code to crash during startup.
>How-To-Repeat:
Compile the attached file with
 gcc -D_REENTRANT -Wall -g -O2 -o multithread-c multithread.c -lpthread -pg
on Solaris 8.

Run the program.

Note the error output
pthread_create: -1

Compare with the same output without -pg, which produces
Hello, world!
as expected.

Compiling the same program as C++ code:
g++ -D_REENTRANT -Wall -g -O2 -o multithread-cxx multithread.c -lpthread -pg

causes the program to segfault during startup.  A back trace shows it crashing under _init():
Program received signal SIGSEGV, Segmentation fault.
0xff26bcb8 in mutex_unlock () from /usr/lib/libthread.so.1
(gdb) bt
#0  0xff26bcb8 in mutex_unlock () from /usr/lib/libthread.so.1
#1  0x42b28 in sbrk ()
#2  0x18480 in monstartup ()
#3  0x18a98 in internal_mcount ()
#4  0x3bddc in memset ()
#5  0xff2630b0 in _clean_thread () from /usr/lib/libthread.so.1
#6  0xff263234 in _t0init () from /usr/lib/libthread.so.1
#7  0xff26bf08 in _init () from /usr/lib/libthread.so.1
#8  0xff3bad88 in ?? ()
#9  0xff3baa00 in ?? ()
#10 0xff3c4d60 in ?? ()
#11 0xff3b2940 in ?? ()

With gcc 2.95.2, the C behavior is the same, but the C++ behavior is different from gcc 3.0.2: it does not crash during startup, but instead fails the same way as C does.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="multithread.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="multithread.c"

I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUgPHB0aHJlYWQu
aD4KI2luY2x1ZGUgPGVycm5vLmg+CgojaWZuZGVmIEVMQVNUCiNkZWZpbmUgRUxBU1QgRVNUQUxF
IC8qIExhcmdlc3QgZXJybm8gdmFsdWUgb24gU29sYXJpcyA4ICovCiNlbmRpZgoKdm9pZCogb3Ro
ZXJfdGhyZWFkKHZvaWQqKTsKCmludCBtYWluKHZvaWQpCnsKICBwdGhyZWFkX3QgdGhyZWFkOwog
IGludCByZXQ7CiAgdm9pZCAqIHZhbHVlOwoKICByZXQgPSBwdGhyZWFkX2NyZWF0ZSgmdGhyZWFk
LCBOVUxMLCAmb3RoZXJfdGhyZWFkLCBOVUxMKTsKICBpZiAocmV0ICE9IDApIHsKICAgIGZwcmlu
dGYoc3RkZXJyLCAicHRocmVhZF9jcmVhdGU6ICVkXG4iLCByZXQpOwogICAgaWYgKHJldCA+IDAg
JiYgcmV0IDw9IEVMQVNUKSB7CiAgICAgIGZwcmludGYoc3RkZXJyLCAicHRocmVhZF9jcmVhdGU6
ICVzXG4iLCBzdHJlcnJvcihyZXQpKTsKICAgIH0KICAgIHJldHVybiAxOwogIH0KCiAgcmV0ID0g
cHRocmVhZF9qb2luKHRocmVhZCwgJnZhbHVlKTsKICBpZiAocmV0ICE9IDApIHsKICAgIGZwcmlu
dGYoc3RkZXJyLCAicHRocmVhZF9qb2luOiAlZFxuIiwgcmV0KTsKICAgIGlmIChyZXQgPiAwICYm
IHJldCA8PSBFTEFTVCkgewogICAgICBmcHJpbnRmKHN0ZGVyciwgInB0aHJlYWRfam9pbjogJXNc
biIsIHN0cmVycm9yKHJldCkpOwogICAgfQogICAgcmV0dXJuIDE7CiAgfQogIAogIHJldHVybiAw
Owp9CgoKdm9pZCAqIG90aGVyX3RocmVhZCh2b2lkICpmb28pCnsKICBwcmludGYoIkhlbGxvLCB3
b3JsZCFcbiIpOwoKICByZXR1cm4gTlVMTDsKfQo=