_dl_get_ready_to_run does not make it

Rob Landley rob at landley.net
Sat Apr 17 05:41:30 UTC 2010


On Saturday 03 April 2010 04:57:32 Sasha Sirotkin wrote:
> I made some modifications to my kernel and managed to ruin dynamic
> linking, more specifically _dl_get_ready_to_run does not make it. This
> is certainly my fault, i.e. the result of my experiments, but the
> question is - what could go wrong and/or how to debug it?
>
> Thanks a lot.

Speaking of which, is there any documentation on how dynamic linkers are 
supposed to work in uClibc?

I bumped into three of the Microblaze guys at CELF (including the guy who 
wrote their gcc support), and they said that they've largely lost interest in 
uClibc because they thought the project had died without ever achieving NPTL 
support, and were forced to switch to eglibc (common theme at the conference, 
I tried to explain the how the "project tumor" of buildroot forking off stalled 
this project the way the "project tumor" of QEMU stalled Tinycc, but that we'd 
_recovered_ and were shipping releases again.

Anyway, I may have volunteered to get dynamic linking working on Microblaze.  
(They offered to buy me a case of energy drinks.  And hey, qemu supports this 
target so I had to add it to FWL at some point before the 1.0 release 
anyway...)

And while I'm at it, I'd like to get dynamic linking working on sparc32 too.  
That works fine in glibc, but immediately bus errors in uClibc.  (Static 
linking works fine now, after I fixed stat.h in the kernel anyway...)

I've tried reading through the dynamic linker source, but the flow of control 
is a bit non-obvious and the end result (on sparc) is "the linker passes 
control to main(), which then dies horribly".

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the uClibc mailing list