Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Nov 2002 00:12:45 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Max Khon <fjoe@iclub.nsu.ru>
Cc:        Jake Burkholder <jake@locore.ca>, current@FreeBSD.ORG
Subject:   Re: libc size
Message-ID:  <3DC77D7D.AFBE56EE@mindspring.com>
References:  <3DC17C7F.9020308@acm.org> <20021031140542.W86715-100000@volatile.chemikals.org> <20021031220633.3acd0b53.flynn@energyhq.homeip.net> <3DC1AB26.5020708@acm.org> <20021103155858.3be6eda9.flynn@energyhq.homeip.net> <3DC6CB56.8090809@acm.org> <20021104215734.GA47193@dragon.nuxi.com> <20021105125454.A51180@iclub.nsu.ru> <20021105021823.T22677@locore.ca> <20021105132142.A52607@iclub.nsu.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
Max Khon wrote:
> hi, there!
> Ok, I put the patch and test program to
> http://people.freebsd.org/~fjoe/libdl.tar.bz2.
> 
> Patches are made against RELENG_4 (and all tests were done on RELENG_4)
> but it will not be that hard to port everything to -CURRENT.
> This is just a proof-of-concept work-in-progress.
> 
> The plan is to add this stuff (rtld sources with -DLIBDL) to libc.a
> so statically linked programe will have dlopen/dlsym etc.

It's interesting, except for being bz2'ed.  It's not like the
Unisys patent hasn't expired yet... 8-).

I have some similar patches; the main difference is that mine
are actually a standalone library.  It utilizes the ".init"
section to cause the initialization to take place normally,
as per a standard constructor.

Right now, my patches don't work with C++ because the replace
the ".init" section.  I have a modified version that actually
uses the constructor list in the standard ".init" section,
instead.

The main issue is the initialization of crt.crt_bp (normally,
this is done via "_callmain").

The problem is that in calling __do_dynamic_link(), the argv
argument is NULL in the constructor case.  Basically, this
means that the constructor code has to be modified to pass it
in to each initially constructed object... the constructor
has to change from a void to a void *, which most constructors
ignore, for it to work.

This is also a requirement, if you want the loaded shared obects
that resolve external symbol references to symbols defined by
the binary (e.g. as if they were dlopen'ed by a dymanically
linked binary).


> Problems with current patches are:
> - I do not know what to do on alpha with _GOT_END_ and
> _GLOBAL_OFFSET_TABLE_ symbols. I had to use ld.so.script
> to solve missing _GOT_END_ problem and ifdef out _GLOBAL_OFFSET_TABLE_
> usage from alpha/reloc.c for second problem. An advice from alpha rtld
> guru will be very useful

That's not me.  8-(.  I think this can be done without that,
though, if you make the changes in the crt0 code, instead.


> - gdb support for shared objecject dlopened from statically linked
> program is broken

This is because of the argv, which is really the startup frame base
address, which contains that information; it's not being initialized
in the case where you're calling it.  You really need to modify the
crt0 code, and duplicate the dlopen mappings in a libdlopen, instead
of modifying ld.so.


> - rtld_exit() is not called on exit so fini functions are not
> called on exit

I had the same problem; mine came from stealing the section entry;
the way to deal with this is to map the base frame so you can add
an internal .fini traversal function to the atexit().  This has to
be done in a reversible way, so you can't actually use atexit(3)
itself to do the job.


> - probably more stuff could be #ifdef'ed out from rtld when it is compiled
> with -DLIBDL

I don't think so, actually.  The question is how the symbols get
in, in the first place.


> - xmalloc and friends names in rtld sources probably should be prepended
> with an underscore to prevent name clashes (if this stuff will be included
> in libc.a)

You can actually deal with this by forcing the load of libc.so, the
first time the dlopen() itself is called, if it's not loaded already,
so the symbols will be available.  It's ugly, but it works, in lieu
of linking all .so's that make libc calls against libc.so (like you'd
reasonably expect).

-- Terry

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?3DC77D7D.AFBE56EE>