Question

I have a stripped ld.so that I want to replace with the unstripped version (so that valgrind works). I have ensured that I have the same version of glib and the cross compiler.

I have compiled the shared object, calling ‘file’ on it shows that it is compiled correctly (the only difference with the original being the ‘unstripped’ and being about 15% bigger). Unfortunately, it then causes a kernel panic (unable to init) on start up. Stripping the newly compiled .so, readelf-ing it and diff-ing it with the original, shows that there were extra symbols in the new version of the .so . All of the old symbols were still present, so what I don’t understand is why the kernel panics with those extra symbols there.

I would expect the extra symbols to have no affect on the kernel start up, as they should never be called, so why do I get a kernel panic?

NB: To be clear – I will still need to investigate why there are extra symbols, but my question is about why these unused symbols cause problems.

Answer 1

The kernel (assuming Linux) doesn’t depend on or use ld.so in any way, shape or form. The reason it panics is most likely that it can’t exec any of the user-level programs (such as /bin/init and /bin/sh), which do use ld.so.

As to why your init doesn’t like your new ld.so, it’s hard to tell. One common mistake is to try to replace ld.so with the contents of /usr/lib/debug/ld-X.Y.so. While that file looks like it’s not much different from the original /lib/ld-X.Y.so, it is in fact very different, and can’t be used to replace the original, only to debug the original (/usr/lib/debug/ld-X.Y.so usually contains only debug sections, but none of code and data sections of /lib/ld-X.Y.so, and so attempts to run it usually cause immediate SIGSEGV).

Perhaps you can set up a chroot, mimicking your embedded environment, and run /bin/ls in it? The error (or a core dump) this will produce will likely tell you what’s wrong with your ld.so.