[uClibc]Broken linker behaviour

Erik Andersen andersen at lineo.com
Mon Jun 18 18:12:50 UTC 2001


On Mon Jun 18, 2001 at 07:02:39AM -0700, Shane Nay wrote:
> Erik,
> 
> This is strange, but I noted it's from ld.so, so maybe it's kosher but...
> 
> Anyway, I got to the point where on ARM the interprettor is actually mostly 
> functioning.  It's able to resolve all the functions inside of itself, loads 
> up the libraries, but then when it goes to resolve the functions within the 
> libraries things get a little broken.  Now I know how to fix it, and that's 
> not my real concern, my concern is the broken part.

Awesome!!!

> The broken part is this...:
> Okay, the _dl_linux_resolve routine calls the _dl_linux_resolver and then it 
> overwrites the address to itself in tpntr to be the actual function (so the 
> resolver doesn't have to get called subsequently), and then it calls the 
> actual function.  (via jump rather than jump/link, so that on return it goes 
> back to the original caller)  Now this is all quite efficient, except that...:


My understanding of how it is working (and again, I could be wrong -- x86 asm
was never my strong point, and the x86 asm in i386/resolv.S is very confusing
-- it took me hours to figure out what was going on and document it and fix it
up so it behaved itself), is that we _should_ be doing a lazy fixup of the jump
relocations, by pointing them all to hit _dl_linux_resolve when first called,
which then does the self-modifying thing and calls the intended jump target.
Thereafter, jumps to that location should be fast as it will go directly, and
will no longer call _dl_linux_resolve.

> The interprettor is resolving functions before they are actually called by 
> code in the application.  Which means that basically a bunch of functions are 
> getting called without having any proper arguments.  This is a Bad Thing 
> because 1) We are going to spend a lot of time calling functions we don't 
> really need to call 2) We're going to be calling a lot of functions with 
> bogus parameters which has extraordinarly undefined results.
> 
> Am I reading this wrong?  Or is something broken in my code that is causing 
> these functions to be resolved before they should be?

You have to understand that I adopted this code from a pragmatic standpoint
(since it already worked for x86), but I have been steadily and incrementally
rewriting it as I find things that can be done in a less sucky way.  Like
fixing all the string and syscalls to be common, discriminating between the
inline and non-inline versions to save space, and figuring out what the heck
this thing is doing and documenting it so I can fix it.  One of the next items
on my hitlist is to split up _dl_boot().  Once _dl_boot has fixed up its own
function pointers, everything else thereaftr can be broken out into manageable
functions (a function that is 944 lines long is broken in my book).

Anyways, back to the issue at hand... (sorry about the rant).  I will have to
read that part of the code to be sure.  I understood it was doing lazy fixups
on the jump relocations (hense the magic with the _dl_linux_resolve function.
If indeed it is walking through and _calling_ each function once to force the
fix up, that is really dump.  If we are going to force startup resolution of
all the jump relocations (which is what you are describing seems to be
happening), then we should trash the _dl_linux_resolve crap and simply resolve
all the jump relocations in a loop written in C code.  

As I think about it, we probably want that to be the default anyways, since as
a rule, whenever I can eliminate asm code in uClibc for the default case, I do.
Asm is fine when there is either no other way to do it (ie we _have_ to do it
in asm), or when we have a nice generic way to do it, but someone wants to code
up and arch specific optimized version.

I've got some stuff I need to get done today, so I'm not sure I'll have time
to read through this and check till tomorrow.

> Anyway, in terms of ARM progress, basically the only thing I haven't 
> implemented is over-writing the tpnt'er with the proper address.  Once that's 
> done my infinite loop should go away, and maybe we'll have a functioning 
> interprettor.
> 
> Thanks,
> Shane Nay.
> (Hey, I'm just happy because _dl_fdprintf is working with normal strings..., 
> makes life *much* easier)


And may I say, for the record, that you rock.  This is excellent progress!

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--





More information about the uClibc mailing list