Subject: port-mips/22754: mips ld.elf_so picks weak alias over strong alias
To: None <gnats-bugs@gnats.netbsd.org>
From: None <he@netbsd.org>
List: netbsd-bugs
Date: 09/12/2003 11:12:44
>Number: 22754
>Category: port-mips
>Synopsis: mips ld.elf_so picks weak alias over strong alias
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: port-mips-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Sep 12 09:13:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Havard Eidnes
>Release: NetBSD 1.6Z Sep 8 2003
>Organization:
>Environment:
System: NetBSD viola.urc.uninett.no 1.6Z NetBSD 1.6Z (VIOLA) #3: Mon Sep 8 14:44:31 CEST 2003 he@viola.urc.uninett.no:/usr/obj/sys/arch/sgimips/compile/VIOLA sgimips
Architecture: mips
Machine: sgimips
>Description:
During an attempt at building X11 sets for -current sgimips, I
stumbled across this problem that the "makekeys" program dumps
core. The program is compiled like this:
gcc -o makekeys -O2 -ansi -Dasm=__asm -I../.. -I../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DUSE_NBSD_THREADLIB -DHAS_SNPRINTF -DLIBX11 util/makekeys.c -L/usr/X11R6/lib -lpthread -Wl,-rpath,/usr/X11R6/lib -Wl,-rpath-link,../../exports/lib -Wl,-rpath,/lib
and it fails with
./makekeys < ../../exports/include/X11/keysymdef.h > ks_tables_h
[1] Abort trap (core dumped) ./makekeys <../....
*** Failed target: ks_tables.h
*** Failed command: ./makekeys < ../../exports/include/X11/keysymdef.h > ks_tables_h
*** Error code 134
Stop.
(which doesn't stop the make job, BTW; I thouhgt it should
have...)
The stack backtrace in the core dump looks like this:
(gdb) where
#0 0x3007e364 in kill ()
#1 0x30081ee4 in __libc_mutex_unlock ()
#2 0x3011621c in __cxa_atexit ()
#3 0x301165a0 in atexit ()
#4 0x400b80 in _rtld_setup ()
#5 0x4009bc in _start ()
#6 0x2650 in rtld_start ()
#7 0x2650 in rtld_start ()
#8 0x2650 in rtld_start ()
#9 0x2650 in rtld_start ()
etc. etc. (rtld_start repeats -- another bug?)
I've single-stepped through the startup of the program, and it
appears that the debugger thinks that __libc_mutex_lock and
__libc_mutex_unlock is the same thing due to the definition of
both as a weak alias for __libc_mutex_catchall_stub:
__weak_alias(__libc_mutex_lock,__libc_mutex_catchall_stub)
__weak_alias(__libc_mutex_unlock,__libc_mutex_catchall_stub)
and __libc_mutex_catchall_stub checks to see if the program is
threaded, and if so, aborts, as observed.
However, __libc_mutex_lock is defined as a strong alias in
libpthread's pthread_mutex.c:
__strong_alias(__libc_mutex_lock,pthread_mutex_lock)
and I would have thought that that binding should have been
preferred over the weak alias? (I'm threading on thin ice
here, but other platforms appear to do this in the expected
manner.)
>How-To-Repeat:
Try to build X11 on -current sgimips; watch the makekeys
program fail as shown above.
>Fix:
I do not know, sorry.
I do however think that the problem observed in PR#19183 is
related to this problem (wrong malloc/free used in tcsh when
the user supplies his own versions).
>Release-Note:
>Audit-Trail:
>Unformatted: