Date: Thu, 21 May 1998 17:42:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: syssgm@dtir.qld.gov.au (Stephen McKay) Cc: tlambert@primenet.com, freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: Fix for undefined "__error" and discussion of shared object versioning Message-ID: <199805211742.KAA18688@usr01.primenet.com> In-Reply-To: <199805210515.PAA07271@troll.dtir.qld.gov.au> from "Stephen McKay" at May 21, 98 03:15:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Use the real symbol names. I don't know why what you are doing won't > >work, but it's *not* what I'm doing, wo it really doesn't matter > >why it doesn't work because it's the wrong thing to do anyway. > > All I did was add a variable (fake_used) that is incremented every time > the __error stand-in (called ___error) is called. In other words, I > instrumented your solution, nothing more. The instrumentation shows > that ___error is called when we expect it not to be called. This is > why I claim that this fix doesn't work. You renamed the symbol, and didn't reacquire it from a subsequently loaded shared library. Because libc (or libc_r) is loaded before the libraries which depend on its symbols, its weak symbols should take precedence. Loading should occur in reverse link order. > To show it really working (if it does work) would require multiple > threads that have different errno values. Showing one thread having > a single errno value is not sufficient. I don't understand your claim. Have you looked at: /usr/src/lib/libc_r/sys/__error.c /usr/src/lib/libc_r/uthread/uthread_seterrno.c ??? The initial thread gets the address of the global "errno"; subsequent threads get the address of a thread specific errno: &_thread_run->error Which is derived from the per thread context structure for the running thread. I *EXPECT* the the stand-in will be called by programs that are *bogusly* NOT relinked against libc, as they should be. For programs *already* linked against libc_r instead of libc, or linked against the new libc, I *EXPECT* the standin to *NEVER* be called. If your program is already linked against libc_r, then *BY DEFINITION*, you aren't having the "undefined __error()" problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805211742.KAA18688>