Вопросы по examples/linux386

[andre...@gmail.com]

Добрый день!

Во-первых, большое спасибо за интересный и нужный проект!

Мы сейчас разрабатываем плату на ВМ10Я и хотим отладить аппаратно-независимые части (сетевой обмен, в основном) кода на обычной машине.

Попробовали запустить пример linux386 (с сетью через TUN/TAP-интерфейс), однако столкнулись с проблемами.

1. Пример не собирался, т.к. в sources/tap/tap.h не было определения arp_t. Вылечилось добавлением #include <net/arp.h>.
2. По-умолчанию в Makefile собирается только хостовое приложение (ответная часть для теста)  tcp-receiver.
3. При запуске test_tcp_sender он обваливается на функции siglongjmp():

arch_task_switch (target=0x8054300) at ~/uos/uos-embedded-read-only/sources/kernel/linux386/machdep.c:35
35              if (sigsetjmp (task_current->stack_context, 1) == 0) {
(gdb)

36                      task_current = target;
(gdb)
37                      siglongjmp (task_current->stack_context, 1);
(gdb)
*** longjmp causes uninitialized stack frame ***: ~/uos/uos-embedded-read-only/examples/linux386/test_tcp_sender terminated

======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x50)[0xb7f66700]
/lib/libc.so.6(+0xe366a)[0xb7f6666a]
~/uos/uos-embedded-read-only/examples/linux386/test_tcp_sender[0x80493b6]
~/uos/uos-embedded-read-only/examples/linux386/test_tcp_sender[0x8048b5c]
~/uos/uos-embedded-read-only/examples/linux386/test_tcp_sender[0x8048c57]
/lib/libc.so.6(__libc_start_main+0xe6)[0xb7e99bb6]
~/uos/uos-embedded-read-only/examples/linux386/test_tcp_sender[0x8048711]
======= Memory map: ========
08048000-08053000 r-xp 00000000 08:14 954898     ~/uos/uos-embedded-read-only/examples/linux386/test_tcp_sender
08053000-08054000 r--p 0000a000 08:14 954898     ~/uos/uos-embedded-read-only/examples/linux386/test_tcp_sender
08054000-08055000 rw-p 0000b000 08:14 954898     ~/uos/uos-embedded-read-only/examples/linux386/test_tcp_sender
08055000-0807a000 rw-p 00000000 00:00 0          [heap]
b7e64000-b7e80000 r-xp 00000000 08:13 16990      /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/libgcc_s.so.1
b7e80000-b7e81000 r--p 0001c000 08:13 16990      /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/libgcc_s.so.1
b7e81000-b7e82000 rw-p 0001d000 08:13 16990      /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/libgcc_s.so.1
b7e82000-b7e83000 rw-p 00000000 00:00 0
b7e83000-b7fc2000 r-xp 00000000 08:13 5922       /lib/libc-2.11.2.so
b7fc2000-b7fc4000 r--p 0013f000 08:13 5922       /lib/libc-2.11.2.so
b7fc4000-b7fc5000 rw-p 00141000 08:13 5922       /lib/libc-2.11.2.so
b7fc5000-b7fc8000 rw-p 00000000 00:00 0
b7fe0000-b7fe1000 rw-p 00000000 00:00 0
b7fe1000-b7fe2000 r-xp 00000000 00:00 0          [vdso]
b7fe2000-b7ffe000 r-xp 00000000 08:13 5871       /lib/ld-2.11.2.so
b7ffe000-b7fff000 r--p 0001b000 08:13 5871       /lib/ld-2.11.2.so
b7fff000-b8000000 rw-p 0001c000 08:13 5871       /lib/ld-2.11.2.so
bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]

Program received signal SIGABRT, Aborted.
0xb7fe1424 in __kernel_vsyscall ()

Куда следует копать в таком случае? Попробуем разобраться сами, но вдруг кто-нибудь из знающих людей поскажет верное направление.

Заранее признателен,

Андрей.

[Serge V.]

Добрый день, Андрей!

Спасибо. Радует, что проект активно используется и развивается.

Тут проблема связана с так называемым "pointer mangling" в Линуксе. Для защиты от вирусов и троянов адреса стека и возврата в jmp_buf хранятся в слегка искаженном виде. Это фича библиотеки glibc. Подробнее здесь: https://sourceware.org/glibc/wiki/PointerEncryption

Примеры linux386 точно работали года три назад. Я так отлаживал протокол TCP. Вероятно, с тех пор библиотека glibc изменилась. Возможно, другой способ шифровки указателей. Гляньте исходники longjmp(). 

С уважением,

Сергей Вакуленко

среда, 17 сентября 2014 г., 7:24:31 UTC-7 пользователь andre...@gmail.com написал: