LINUX.ORG.RU

Можно ли собрать бинарик с кастомным /lib/ld.so.1 по-умолчанию в качестве интерпритатора бинарика?

 , ,


2

4

Смеркалось.

Собрал valgrind под мипсельную железяку. При запуске на железяке простит libc6-dbg. ld.so.1 и libc6.so.6 есть не стрипнутые, если запустить все в чруте, работает. А вот как запустить валгринд в основной системе(где либы стрипнутые), либо собрать валгринд так чтоб он по умолчанию искал ld.so.1 не в /lib/, а в /tmp/valgrind/lib ?

★★★★★

Да, можно.

$ gcc test.c 
$ file a.out 
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=05a824db1dcfc0cac4ebfb73732e40b553d29fda, not stripped
$ gcc -Wl,--dynamic-linker=/dev/null test.c
$ file a.out 
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /dev/nul, for GNU/Linux 3.2.0, BuildID[sha1]=5a2c0be9065ac0c2bfffb905a6ce682059361a31, not stripped
$ ./a.out
zsh: Отказано в доступе: ./a.out

Не обращай внимания на вывод file, у меня он какой-то сломанный. O_o. readelf нормально показывает.

a1batross ★★★★★
()
Последнее исправление: a1batross (всего исправлений: 1)
Ответ на: комментарий от Anoxemian
[root@mipsel-device]# LD_PRELOAD=/tmp/valgrind/lib/ld.so.1:/tmp/valgrind/lib/libc.so.6 /tmp/valgrind/bin/valgrind /mnt/nv/epg
==3231== Memcheck, a memory error detector
==3231== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3231== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==3231== Command: /mnt/nv/epg
==3231== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      index
valgrind:  in an object with soname matching:   ld.so.1
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld.so.1
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

[root@mipsel-device]# 

так применяю?

у меня еще вопрос насчет libс: тот факт, что я подменю интерпретатор, никаким боком ведь не означает что я подменю либси? А надо ее. У кого какие идеи?

pihter ★★★★★
() автор топика
Ответ на: комментарий от moonmadness

Помогает, интерпретатор изменяется, но валгринд не заводится. Надо чего-то выдумывать с либси.

pihter ★★★★★
() автор топика
Ответ на: комментарий от a1batross

собирается, вроде, верно:

$ CC=${CROSS_PREFIX}gcc CPP=${CROSS_PREFIX}cpp AR=${CROSS_PREFIX}ar LDFLAGS="-Wl,--dynamic-linker=/tmp/valgrind/lib/ld.so.1" ./configure --host=mipsel-linux-gnu --prefix=/tmp/valgrind

...


$ file valgrind
valgrind: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter /tmp/valgrind/lib/ld.so.1, for GNU/Linux 2.6.37, not stripped

но при запуске — то же самое :(

pihter ★★★★★
() автор топика
Ответ на: комментарий от moonmadness

пробовал и то и другое – не помогает

pihter ★★★★★
() автор топика

А может быть такое что исследуемый бинарик должен быть слинкован с дебажной ld|libc ?

pihter ★★★★★
() автор топика

Не могу понять, зачем тебе рассказывают про LD_PRELOAD и LD_LIBRARY_PATH. Интерпретатор (ld.so) загружается ядром, строго по тому пути, который указан в бинарнике, а уже он читает rpath и переменные среды и танцует прочие танцы.

Я бы попробовал для начала patchelf --set-interpreter /tmp/valgrind/lib/ld.so.1 valgrind

В любом случае valgrind'у нужен нестрипнутый ld.so.

proud_anon ★★★★★
()
Ответ на: комментарий от proud_anon

Интерпретатор (ld.so) загружается ядром, строго по тому пути, который указан в бинарнике, а уже он читает rpath и переменные среды и танцует прочие танцы.

А где про это почитать можно? Спасибо. Хотя бы слова как гуглить на ангельском, чета я ниче не нашел

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Вот есть две статьи от человека, который разрабатывал в ядре вызов execveat:

1. How programs get run
2. Её продолжение: How programs get run: ELF binaries

Про то, что происходит после загрузки интерпретатора ELF, — в man 8 ld-linux.so

А valgrind-то заработал в итоге?

proud_anon ★★★★★
()
Ответ на: комментарий от proud_anon

Да. Секрет был в том, что не стрипнутый ld.so.1 надо было подсовывать исследуемуму бинарику. Но возможно, разгадка не только в этом, – выну жопА из воды, вернусь к работе, разберусь точно и отпишусь сюда для будущих поколений

pihter ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.