отладка до победного

Если валится с сегфолтом, убирай точку останова и запускай программу. При сегфолте gdb автоматом выдаст тебе данные

прчитать ман по gdb?

continue после точки останова?

поискать по форуму и в гугле...

Нет, это не сегфолт точно, отладка ядра на qemu.

И в меню gdb после падения я увижу connection closed ( или как-то так), и все.

Читал, просто отдельные командочки. Тут что-то вроде скрипта нужно.

И в меню gdb после падения я увижу connection closed ( или как-то так), и все.

Мы точно про один и тот же gdb говорим? А ты пробовал? Ты получишь сообщение, что программа получила сигнал SIGSEGV. Вот тут-то и надо дать команду bt

(gdb) set $i=0
(gdb) display/i $pc
1: x/i $pc
=> 0x7f0576 <main(int, char**)+15>:	mov    -0x10(%rbp),%rdx
(gdb) while $i < 5
 >si
 >set $i=$i+1
 >end
0x00000000007f057d	1771	  return v8::Shell::Main(argc, argv);
1: x/i $pc
=> 0x7f057d <main(int, char**)+22>:	mov    %rdx,%rsi
0x00000000007f0580	1771	  return v8::Shell::Main(argc, argv);
1: x/i $pc
=> 0x7f0580 <main(int, char**)+25>:	mov    %eax,%edi
0x00000000007f0582	1771	  return v8::Shell::Main(argc, argv);
1: x/i $pc
=> 0x7f0582 <main(int, char**)+27>:	
    callq  0x7f012c <v8::Shell::Main(int, char**)>
v8::Shell::Main (argc=0, argv=0x7fffffffdd30) at ../src/d8.cc:1670
1670	int Shell::Main(int argc, char* argv[]) {
1: x/i $pc
=> 0x7f012c <v8::Shell::Main(int, char**)>:	push   %rbp
0x00000000007f012d	1670	int Shell::Main(int argc, char* argv[]) {
1: x/i $pc
=> 0x7f012d <v8::Shell::Main(int, char**)+1>:	mov    %rsp,%rbp
(gdb) 

Сколько щелкать выбираете сами.

Читал, просто отдельные командочки.

Из этих «командочек» можно писать скрипты.

Тут что-то вроде скрипта нужно.

В мане по свежим gdb есть руководство по скриптингу на Python.

https://sourceware.org/gdb/onlinedocs/gdb/

Главы 22 и 23.

Нет, не получаю, я ж говорю, сама программа запущена на qemu, отладка удаленная. Программа падает таким образом, что кладет qemu

./launch.sh: line 1:  1043 Аварийный останов         (core dumped) qemu-system-arm -s -S -m 1024M -M vexpress-a15 -nographic -kernel u-boot -sd flash.img

(gdb) continue
Continuing.
Remote connection closed

Как насчет вкомпилять debug info (-g) а потом запустить в valgrind

может, я что-то не понимаю, но ты на гостевой системе настрой, чтобы корка сохранялась в файл, а потом её, post-mortem, так сказать изучи, не?

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

(gdb) set $i=0
(gdb) while $i < 5
 >next
 >set $i=$i+1
 >end

142	    iounmap(wugen_base);
144	    return 0;
145	}
0x0027a414 in ?? ()
Cannot find bounds of current function

Можно по подробнее пожалуйста. Когда я открываю целевой файл с помощью gdb, последней строкой я вижу

Reading symbols from /home/likan/versatile/xen/xen/xen-syms...done

Что за корка? Как это настроить?

Не уверен что это значит что инфа вкомпилена.

Valgrind умеет упасть со стектрейсом и ошибкой в стиле Invalid read of size 4 bytes at myapp.cpp:234 или ругаться ворнингами Execution flow depends on unitialized variable. Он много чего умеет. Не уверен насчет арма.

Ну если в я gdb могу увидеть Си-шный код, то наверное вкомпилена.

когда экран заполняется кодом, нужно жать Enter

set pagination off, ЕМНИП

ну, core dump.
ulimit -c unlimited и https://sigquit.wordpress.com/2009/03/13/the-core-pattern/

Собственно говоря отлаживать при помощи gdb шагом arm иногда весьма затруднительно, впрочем это зависит от того какой вид точек останова используется для шага.

gdb в принципе способен отлаживать программы где только часть источников скомпилирована с отладкой. Однако при движении по n и s если попасть в подобную процедуру (или ассемблерный код, код не покрытый коррекной информацией), то возможны разнообразные сообщения и пропуск инструкций до попадания в код собранный под отладкой. Так как возможны еще эффекты связанные с оптимизацией, то сам предпочитаю в критических ситуациях именно si или ni - как-то надежнее. Заметим, что при проходе по скомпилированным под отладкой С-код тоже будет.