LINUX.ORG.RU

Valgrind для ARM

 


0

1

Собираю Valgrind для linux-uclibcgnueabi на железке sam9m10g45-ek

CC=arm-linux-uclibcgnueabi-gcc CFLAGS=-pipe -Os -mtune=arm9tdmi -mabi=aapcs-linux -msoft-float -I/opt/toolchains/arm926t-uclibcgnueabi/usr/include LDFLAGS=-L/opt/toolchains/arm926t-uclibcgnueabi/usr/lib ../valgrind-3.8.1/configure --prefix=/home/splinter/ARMBUILD/valgrind --host=armv7-unknown-linux --target=armv7-unknown-linux --build=i486-slackware-linux 

make && make install Посмотрел через ldd бинарнику valgrind нужен только

	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4000e000)
	libc.so.0 => /lib/libc.so.0 (0x40021000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)
Пытаюсь запускать получаю:
[root@cpu-unit ~]# /usr/bin/valgrind    
Illegal instruction

через strace:
execve("/usr/bin/valgrind", ["/usr/bin/valgrind"], [/* 18 vars */]) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40005000
stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=2866, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
mmap2(NULL, 2866, PROT_READ, MAP_SHARED, 3, 0) = 0x40006000
close(3)                                = 0
open("/lib/libgcc_s.so.1", O_RDONLY)    = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=43172, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0p'\0\0004\0\0\0\274"..., 4096) = 4096
mmap2(NULL, 77824, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000e000
mmap2(0x4000e000, 41384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x4000e000
mmap2(0x40020000, 964, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xa) = 0x40020000
close(3)                                = 0
munmap(0x40007000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=527131, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0p\243\0\0004\0\0\0\324"..., 4096) = 4096
mmap2(NULL, 581632, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40021000
mmap2(0x40021000, 523492, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x40021000
mmap2(0x400a8000, 5000, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x7f) = 0x400a8000
mmap2(0x400aa000, 16924, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400aa000
close(3)                                = 0
munmap(0x40007000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=527131, ...}) = 0
close(3)                                = 0
munmap(0x40006000, 2866)                = 0
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=21200, ...}) = 0
mprotect(0x400a8000, 4096, PROT_READ)   = 0
mprotect(0x4000c000, 4096, PROT_READ)   = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
--- SIGILL (Illegal instruction) @ 0 (0) ---
+++ killed by SIGILL +++

Где я ошибся?

★★★★★

Ответ на: комментарий от dimon555
Program received signal SIGILL, Illegal instruction.
0x00009104 in main (argc=1, argv=0xbef89b74, envp=0xbef89b7c) at ../../valgrind-3.8.1/coregrind/launcher-linux.c:324
324	in ../../valgrind-3.8.1/coregrind/launcher-linux.c

там такой кусок

/* Figure out the name of this executable (viz, the launcher), so
      we can tell stage2.  stage2 will use the name for recursive
      invocations of valgrind on child processes. */
   memset(launcher_name, 0, PATH_MAX+1);
   r = readlink("/proc/self/exe", launcher_name, PATH_MAX);
   if (r == -1) {
      /* If /proc/self/exe can't be followed, don't give up.  Instead
         continue with an empty string for VALGRIND_LAUNCHER.  In the
         sys_execve wrapper, this is tested, and if found to be empty,
         fail the execve. */
      fprintf(stderr, "valgrind: warning (non-fatal): "
                      "readlink(\"/proc/self/exe\") failed.\n");
      fprintf(stderr, "valgrind: continuing, however --trace-children=yes "
                      "will not work.\n");
   }

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

а собсвенно может посмотреть на IP и какую инструкцию пытается выполнить а так же возможно найти её через objdump, может оно там невыровнено или ещё что?

ты на эмуляторе запускаешь или на реальной плате? может armv7 там не полностью поддерживается? а может gcc не ту инструкцию пихает... попробуй без оптимизаций

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

а собсвенно может посмотреть на IP

непонял

ты на эмуляторе запускаешь или на реальной плате?

в сабже написанно на железке sam9m10g45-ek

может armv7 там не полностью поддерживается?

В valgrind для арма как я понял только это поддерживает.

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

ip - instruction pointer, ошибься да, наверное лучше program counter.

Illegal instruction

надо посмотреть, действительно ли процессору подсовывают нелегальную инструкцию

dimon555 ★★★★★ ()

Ну прям по моим стопам :)

Valgrind поддерживает далеко не все виды процессоров ARM. Они отличаются по набору команд и еще чем-то. Мы долго бились, пытаясь заставить его работать на нашей платформе, и в итоге бросили эту затею. Стали ловить утечки памяти подручными дедовскими методами.

Deleted ()
Ответ на: комментарий от splinter

Мы сделали preload-библиотечку, перехватывающую все malloc/free, и ведущую учет утечек. На каждое выделение памяти делался также дамп стека. Потом по сигналу библиотечка все это вываливала на консоль, и начинался анализ - разгребание утечек, размотка стека при помощи gdb, попытки понять, что утекло изначально, а что как следствие. В итоге за полтора человеко-месяца были найдены и устранены четыре (sic!) бага, приводивших к утечке памяти. Дело осложнялось такими обстоятельствами, как неработающая автоматическая размотка стека, C++, CORBA, Boost.

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

Дело осложнялось такими обстоятельствами, как неработающая автоматическая размотка стека, C++, CORBA, Boost.

и это всё пихали в embedded железку на ARM?

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

Мы сделали preload-библиотечку, перехватывающую все malloc/free, и ведущую учет утечек.

а gperftools слабо было взять? к тому же, valgrind полезен далеко не только для поиска утечек

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

gperftools выглядит интересно. Странно, что никто из нас тогда его не нашел :)

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