Re: What I suspect

Linus Torvalds (torvalds@transmeta.com)
Wed, 8 Dec 1999 09:01:12 -0800 (PST)


On Wed, 8 Dec 1999, David S. Miller wrote:
>
> You shouldn't need that for the regular "load libc" case.
>
> Sure you would, a strong symbol override for a weak symbol overrides
> global references everywhere, even in libc itself, not just in the
> application image. See my other email about malloc.

David. I know.

I'm not making myself clear.

Normal programs do NOT re-define their own malloc(). It's useful for
debugging, but it's not considered well-behaved. Most people avoid trying
to redefine library functions (and data) as much as they humanly can. And
that is as it should be. If you want to have an extended malloc(), you
call it xmalloc() etc.

What I'm arguing is that normal programs should not need to do the
relinking AT ALL. Not because it cannot be done, but because it's not
needed. You shouldn't need to even check, because you can tell at
link-time that it is unnecessary. So with pre-linked libraries, once
you've successfully loaded the library at the right address, you just go
go go..

One mmap(). No symbol searching. No mprotect() to mark the library
writable for a while, because in the absense of symbol clashes it would
all be correct anyway.

At that point, the dynamic ELF libraries perform as well as the old stupid
static ones used to do in the common case. And they'll still be dynamic,
they'll just slow down if there are symbol clashes or if they cannot be
loaded at the pre-linked address.

I understand that Uli is working on this. So I'm happy.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/