Date: Wed, 23 Feb 2000 14:31:01 +0100 From: Martin Cracauer <cracauer@cons.org> To: Bruce Evans <bde@zeta.org.au> Cc: Martin Cracauer <cracauer@cons.org>, jdp@FreeBSD.ORG, jkh@FreeBSD.ORG, current@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: extern variables in shared libraries broken (ld.so or mmap bug) Message-ID: <20000223143101.A5971@cons.org> In-Reply-To: <Pine.BSF.4.21.0002232257320.5626-100000@alphplex.bde.org>; from bde@zeta.org.au on Wed, Feb 23, 2000 at 11:29:44PM %2B1100 References: <20000223100036.A4872@cons.org> <Pine.BSF.4.21.0002232257320.5626-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In <Pine.BSF.4.21.0002232257320.5626-100000@alphplex.bde.org>, Bruce Evans wrote:
> diff -c2 localtime.c~ localtime.c
> *** localtime.c~ Fri Jan 28 17:29:18 2000
> --- localtime.c Wed Feb 23 22:51:34 2000
> ***************
> *** 220,224 ****
> settzname P((void))
> {
> ! register struct state * const sp = lclptr;
> register int i;
>
> --- 220,224 ----
> settzname P((void))
> {
> ! register struct state * sp = lclptr;
> register int i;
>
> This seems to fix some of your prooblems.
>
> It works as follows: when sp is declared as const, gcc decides not to
> keep in a register in the default !ALL_STATE case (lclptr is &lclmem in
> this case), since it can "easily" be recovered by computing the address
> constant &lclmem. However, computing the constant turns out to be not
> so easy in the -fpic case -- it takes an extra 8 instructions, including
> a pessimization which gives the bug.
My initial next question would be how this bad code in localtime.c can
affect straight references from the calling program to the symbol
tzname[] without calling code in localtime. And why write accesses
succeed and read accesses fail.
Looking on the assembler code, I guess that the wrong code in
localtime.c leave a wrong value in %ecx, why is used as a base address
by rtld.
Once the wrong code is called, the symbol table is messed up. However,
some calls such as the write test in my shlibs3 example still succeed
because the compiler saved/cached the address from a previous call
(which he is allowed to since the address is constant). Once the code
goes through normal rtld lookup again, it bombs.
Right?
I am not sure how harmless this bug is. `make world` output shows that
the as warning message only occurs in localtime.c. I think a
workaround might be to fix as you suggest and turn the assembler
warning into an error, although in that case users might not be able
to compile valid code into shared libraries.
Where's the bug, anyway? Do we need to fix the compiler or would it be
better to get a newer assembler?
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
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?20000223143101.A5971>