Почему общий объект терпит неудачу, если у него есть дополнительные символы по сравнению с оригиналом

Question

У меня есть раздетый ld.so, который я хочу заменить на незарезанную версию (чтобы работал valgrind).Я удостоверился, что у меня одна и та же версия glib и кросс-компилятора.

Я скомпилировал общий объект, вызов «file» для него показывает, что он скомпилирован правильно (единственная разница с оригиналом заключается в том, что«без ограничений» и примерно на 15% больше).К сожалению, это вызывает панику ядра (неспособность инициировать) при запуске.Извлечение вновь скомпилированного .so, повторное его сопоставление с оригиналом показывает, что в новой версии .so были дополнительные символы.Все старые символы все еще присутствовали, поэтому я не понимаю, почему ядро ​​паникует из-за этих дополнительных символов.

Я бы ожидал, что дополнительные символы не будут влиять на запуск ядра, так какони никогда не должны вызываться, так почему я испытываю панику в ядре?

Примечание: для ясности - мне все еще нужно выяснить, почему существуют дополнительные символы, но мой вопрос о том, почему эти неиспользуемые символы вызывают проблемы.

Answer 1

Ядро (при условии, что Linux) не зависит от или не использует ld.so в любом случае, форме или форме. Причина его паники, скорее всего, заключается в том, что он не может выполнить ни одну из программ уровня пользователя (например, /bin/init и /bin/sh), которые используют ld.so.

Что касается того, почему вашему init не нравится ваш новый ld.so, трудно сказать. Одна распространенная ошибка - попытаться заменить ld.so содержимым /usr/lib/debug/ld-X.Y.so. Хотя этот файл выглядит так, как будто он не сильно отличается от оригинала /lib/ld-X.Y.so, на самом деле он очень отличается и не может использоваться для замены оригинала, только для отладки оригинала (обычно /usr/lib/debug/ld-X.Y.so) содержит только разделы отладки, но ни один из разделов кода и данных /lib/ld-X.Y.so, поэтому попытки запустить его обычно вызывают немедленный SIGSEGV).

Возможно, вы можете настроить chroot, имитируя встроенную среду, и запустить в ней /bin/ls? Это сообщение об ошибке (или дамп памяти), скорее всего, скажет вам, что не так с вашим ld.so.