Re: Weak symbols in libc_r broken?
On Mon, Mar 13, 2000 at 06:12:22PM +1100, John Birrell wrote: I deleted the weak definitions in the _THREAD_SAFE PRSYSCALL in lib/libc/i386/SYS.h and the problem goes away. I don't understand why Jason needed to add them in the first place. I didn't need to add them. At some point during all the changes I made, I mistakenly got it in my mind that the weak aliases had been there before I started mucking with things, and therefore I, uh, left them there. =) Unfortunately, I didn't notice this problem until a week ago, and it was only this weekend that I understood the root of the problem. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weak symbols in libc_r broken?
On 2000-Mar-13 14:45:16 +1100, John Birrell [EMAIL PROTECTED] wrote: the linker gives me the weak symbol version which refers to _thread_sys_nanosleep (i.e. the syscall), instead of the nanosleep function in libc_r. Out of interest, why does nanosleep appear in libc_r.a as a weak symbol version of _thread_sys_nanosleep at all? I would have thought this was unnecessary (and based on my experiments, undesirable). Is there someone with a recent -current system who has time to try this out? I have -current from 9th March and get the same results you do. Looking at last night's buildworld results, there doesn't appear to be any change in the symbols in libc_r.a and when I try manually performing the link with the ld in /usr/obj/..., I still get the same result. ... then libc_r is broken. This is a particularly bad time to discover what appears to be a fairly serious bug in the threaded libraries and/or linker. I just tried fiddling with the order in which uthread_nanosleep.o and nanosleep.o appear in libc_r.a. It seems that the linker always picks the first definition of the symbol found after the first reference to the symbol - whether it is weak or not. Since nanosleep.o appears before uthread_nanosleep.o, the non thread-safe version will be picked. I suspect the only solution is to dispose of the weak symbols - re-ordering the object file isn't an option given the requirement for the non-weak symbol to always appear between the reference and the weak symbol. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weak symbols in libc_r broken?
On Mon, Mar 13, 2000 at 03:16:39PM +1100, Peter Jeremy wrote: Out of interest, why does nanosleep appear in libc_r.a as a weak symbol version of _thread_sys_nanosleep at all? I would have thought this was unnecessary (and based on my experiments, undesirable). I don't think it is necessary. It got caught up in the cancellation changes that Jason made. Is there someone with a recent -current system who has time to try this out? I have -current from 9th March and get the same results you do. Looking at last night's buildworld results, there doesn't appear to be any change in the symbols in libc_r.a and when I try manually performing the link with the ld in /usr/obj/..., I still get the same result. ... then libc_r is broken. This is a particularly bad time to discover what appears to be a fairly serious bug in the threaded libraries and/or linker. I just tried fiddling with the order in which uthread_nanosleep.o and nanosleep.o appear in libc_r.a. It seems that the linker always picks the first definition of the symbol found after the first reference to the symbol - whether it is weak or not. Since nanosleep.o appears before uthread_nanosleep.o, the non thread-safe version will be picked. I suspect the only solution is to dispose of the weak symbols - re-ordering the object file isn't an option given the requirement for the non-weak symbol to always appear between the reference and the weak symbol. I agree. Thanks for helping out. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weak symbols in libc_r broken?
On Mon, Mar 13, 2000 at 02:52:02PM +1100, John Birrell wrote: Is it just me, or are the weak symbols in libc_r confusing the linker? Not just you. Jason and Mike Smith brought this to my attention on Friday. I found that if one takes a fresh -CURRENT and then: cd /usr/src/lib/libc_r cvs -q up -D 1/27/2000 make all install the susp.c code from the AW Ptheads Programming book (http://www.aw.com/cseng/titles/0-201-63392-2/code/) would then work with compiled with "-static -pthread". Your analysis if what is currently happening is correct. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weak symbols in libc_r broken?
On Sun, Mar 12, 2000 at 11:07:40PM -0800, David O'Brien wrote: On Mon, Mar 13, 2000 at 02:52:02PM +1100, John Birrell wrote: Is it just me, or are the weak symbols in libc_r confusing the linker? Not just you. Jason and Mike Smith brought this to my attention on Friday. I found that if one takes a fresh -CURRENT and then: cd /usr/src/lib/libc_r cvs -q up -D 1/27/2000 make all install the susp.c code from the AW Ptheads Programming book (http://www.aw.com/cseng/titles/0-201-63392-2/code/) would then work with compiled with "-static -pthread". I don't think it is the linker's fault. To me it makes no sense to have a weak symbol and a strong symbol of the same name in the same library. I deleted the weak definitions in the _THREAD_SAFE PRSYSCALL in lib/libc/i386/SYS.h and the problem goes away. I don't understand why Jason needed to add them in the first place. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
