отладчик gdb (не работает на реальном железе.)
Модератор: Модераторы разделов
-
- Сообщения: 6
- ОС: slackware 13.1
отладчик gdb
в общем есть небольшой проект работающий под управлением slackware 13.1.
средства разработки - netbeans 7.4 - 8.0. язык - Си.
при работе на одном и том же установочном образе slackware происходит следующее:
на вирт машине (oracle virtual box) - все компилится, выполняется и отлаживается.
на реальном железе (helios от diamond systems) все компилится и запускается. при попытке отладится происходят непонятные глюки. запуск приложения из под gdb - тоже ничего не дает. в чем может быть проблема?
достало уже отлаживатся печатью переменных
пробовал из под gdb, на реальном железе отладить "Hello world" - тоже не отлаживается. где конфликт? что смотреть?
средства разработки - netbeans 7.4 - 8.0. язык - Си.
при работе на одном и том же установочном образе slackware происходит следующее:
на вирт машине (oracle virtual box) - все компилится, выполняется и отлаживается.
на реальном железе (helios от diamond systems) все компилится и запускается. при попытке отладится происходят непонятные глюки. запуск приложения из под gdb - тоже ничего не дает. в чем может быть проблема?
достало уже отлаживатся печатью переменных
пробовал из под gdb, на реальном железе отладить "Hello world" - тоже не отлаживается. где конфликт? что смотреть?
-
- Модератор
- Сообщения: 21001
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: отладчик gdb
Что говорит-то?
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
-
- Сообщения: 6
- ОС: slackware 13.1
Re: отладчик gdb
new thread xxxx
и тишина....
и тишина....
-
- Сообщения: 2041
- Статус: ☮ PEACE ☮
- ОС: открытая и свободная
Re: отладчик gdb
Вы используете потоки? На что выставляете breakpoint? Прогоните программу через strace, скажите на какой функции запнулось выполнение, а лучше - выложите сюда последние строк 20.
Создает/шлет ли программа какие-либо сетевые запросы?
Labor omnia vincit
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
-
- Сообщения: 6
- ОС: slackware 13.1
Re: отладчик gdb
вот пример запуска простенького примера из под отладчика gdb:
root@ugi:~/.netbeans/remote/192.168.0.14/vladmir-Windows-x86/D/working/trunk/develop/ugi_linux/demos/test/test_proj/dist/Debug/GNU-Linux-x86# gdb test_proj
GNU gdb (GDB) 7.5
Copyright (coffee) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/.netbeans/remote/192.168.0.14/vladmir-Windows-x86/D/working/trunk/develop/ugi_linux/demos/test/test_proj/dist/Debug/GNU-Linux-x86/test_proj...done.
(gdb) list
7
8 #include <stdio.h>
9 #include <stdlib.h>
10
11 /*
12 *
13 */
14 int main(int argc, char** argv) {
15
16 int i, j=0;
(gdb) list
17 for(i=0; i<10; i++)
18 {
19 j++;
20 }
21
22 printf("%d \n",j);
23
24 return (EXIT_SUCCESS);
25 }
26
(gdb) b 16
Breakpoint 1 at 0x8048395: file main.c, line 16.
(gdb) run
Starting program: /root/.netbeans/remote/192.168.0.14/vladmir-Windows-x86/D/working/trunk/develop/ugi_linux/demos/test/test_proj/dist/Debug/GNU-Linux-x86/test_proj
Breakpoint 1, main (argc=1, argv=0xbffff454) at main.c:16
16 int i, j=0;
(gdb) s
0xb7f4752e in __old__fxstat64 () from /lib/libc.so.6
(gdb) backtrace
#0 0xb7f4752e in __old__fxstat64 () from /lib/libc.so.6
#1 0xb7ee3c23 in _IO_file_stat_internal () from /lib/libc.so.6
#2 0xb7ed7e1f in _IO_file_doallocate_internal () from /lib/libc.so.6
#3 0xb7ee5aed in _IO_doallocbuf_internal () from /lib/libc.so.6
#4 0xb7ee4633 in _IO_new_file_overflow () from /lib/libc.so.6
#5 0xb7ee3762 in _IO_new_file_xsputn () from /lib/libc.so.6
#6 0xb7eb8d93 in vfprintf () from /lib/libc.so.6
#7 0xb7ec29d0 in printf () from /lib/libc.so.6
#8 0x080483c2 in main (argc=1, argv=0xbffff454) at main.c:22
(gdb) quit
A debugging session is active.
Inferior 1 [process 1370] will be killed.
Quit anyway? (y or n) y
на виртуалке все выполняется без проблем а здесь лезет в либу и затыкается. вместо того чтобы выполнять код пошагово.
root@ugi:~/.netbeans/remote/192.168.0.14/vladmir-Windows-x86/D/working/trunk/develop/ugi_linux/demos/test/test_proj/dist/Debug/GNU-Linux-x86# gdb test_proj
GNU gdb (GDB) 7.5
Copyright (coffee) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/.netbeans/remote/192.168.0.14/vladmir-Windows-x86/D/working/trunk/develop/ugi_linux/demos/test/test_proj/dist/Debug/GNU-Linux-x86/test_proj...done.
(gdb) list
7
8 #include <stdio.h>
9 #include <stdlib.h>
10
11 /*
12 *
13 */
14 int main(int argc, char** argv) {
15
16 int i, j=0;
(gdb) list
17 for(i=0; i<10; i++)
18 {
19 j++;
20 }
21
22 printf("%d \n",j);
23
24 return (EXIT_SUCCESS);
25 }
26
(gdb) b 16
Breakpoint 1 at 0x8048395: file main.c, line 16.
(gdb) run
Starting program: /root/.netbeans/remote/192.168.0.14/vladmir-Windows-x86/D/working/trunk/develop/ugi_linux/demos/test/test_proj/dist/Debug/GNU-Linux-x86/test_proj
Breakpoint 1, main (argc=1, argv=0xbffff454) at main.c:16
16 int i, j=0;
(gdb) s
0xb7f4752e in __old__fxstat64 () from /lib/libc.so.6
(gdb) backtrace
#0 0xb7f4752e in __old__fxstat64 () from /lib/libc.so.6
#1 0xb7ee3c23 in _IO_file_stat_internal () from /lib/libc.so.6
#2 0xb7ed7e1f in _IO_file_doallocate_internal () from /lib/libc.so.6
#3 0xb7ee5aed in _IO_doallocbuf_internal () from /lib/libc.so.6
#4 0xb7ee4633 in _IO_new_file_overflow () from /lib/libc.so.6
#5 0xb7ee3762 in _IO_new_file_xsputn () from /lib/libc.so.6
#6 0xb7eb8d93 in vfprintf () from /lib/libc.so.6
#7 0xb7ec29d0 in printf () from /lib/libc.so.6
#8 0x080483c2 in main (argc=1, argv=0xbffff454) at main.c:22
(gdb) quit
A debugging session is active.
Inferior 1 [process 1370] will be killed.
Quit anyway? (y or n) y
на виртуалке все выполняется без проблем а здесь лезет в либу и затыкается. вместо того чтобы выполнять код пошагово.
-
- Сообщения: 2041
- Статус: ☮ PEACE ☮
- ОС: открытая и свободная
Re: отладчик gdb
У нас тут, на форуме, есть тег [code], используйте его пожалуйста.
Я смотрю, gdb Вы на 32 битной системе запускаете, а функция называется __old__fxstat64 (). Она случайно не x86_64? (:
По поводу трассировки: вывод strace, вывод ldd и вывод file.
Если helloworld не работает, то проблема либо в конфликтах версий библиотек, либо архитектур.
Используйте watch, чтобы отладчик сам сообщал, когда переменная меняет свое значение.
Я смотрю, gdb Вы на 32 битной системе запускаете, а функция называется __old__fxstat64 (). Она случайно не x86_64? (:
По поводу трассировки: вывод strace, вывод ldd и вывод file.
Если helloworld не работает, то проблема либо в конфликтах версий библиотек, либо архитектур.
Используйте watch, чтобы отладчик сам сообщал, когда переменная меняет свое значение.
Labor omnia vincit
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
-
- Сообщения: 1139
- ОС: Fedora
Re: отладчик gdb
Stauffenberg писал(а): ↑09.04.2015 13:17Я смотрю, gdb Вы на 32 битной системе запускаете, а функция называется __old__fxstat64 (). Она случайно не x86_64?
этот системный вызов работает с 64-битными смещениями, а называется он одинаково для всех платформ, и совсем не случайно.
-
- Сообщения: 2041
- Статус: ☮ PEACE ☮
- ОС: открытая и свободная
Re: отладчик gdb
s.xbatob писал(а): ↑09.04.2015 14:12Stauffenberg писал(а): ↑09.04.2015 13:17Я смотрю, gdb Вы на 32 битной системе запускаете, а функция называется __old__fxstat64 (). Она случайно не x86_64?
этот системный вызов работает с 64-битными смещениями, а называется он одинаково для всех платформ, и совсем не случайно.
т.е. на 32 битной платформе будет работать без проблем?
Тогда ждем выводы strace, ldd и file.
Labor omnia vincit
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
-
- Сообщения: 6
- ОС: slackware 13.1
Re: отладчик gdb
сорри что потерялся, командировка...
вот вывод ldd:
вот вывод strace:
вот вывод file:
напомню суть проблемы:
при отладке из под чистого gdb - отладчик не бегает по циклу, а один раз заходит а потом сразу выполняет следующую за циклом строку.
при выполнении отладки через нетбинс - отладчик после остановки на первом брекпоинте, начинает скакать по коду(в пошаговом режиме) хаотично.
запуск на выполнение без отладки в обоих случаях работает корректно.
вот вывод ldd:
Код: Выделить всё
root@ugi:/lib# ldd libc.so.6
/lib/ld-linux.so.2 (0xb7767000)
linux-gate.so.1 => (0xffffe000)
вот вывод strace:
Код: Выделить всё
root@ugi:~/.netbeans/remote/192.168.0.14/vladmir-Windows-x86/D/working/trunk/develop/ugi_linux/demos/test/test_proj/dist/Debug/GNU-Linux-x86# strace ./test_proj
execve("./test_proj", ["./test_proj"], [/* 30 vars */]) = 0
brk(0) = 0x804a000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb786e000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=16593, ...}) = 0
mmap2(NULL, 16593, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7869000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340l\1\0004\0\0\0<"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1649149, ...}) = 0
mmap2(NULL, 1452296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7706000
mprotect(0xb7862000, 4096, PROT_NONE) = 0
mmap2(0xb7863000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c) = 0xb7863000
mmap2(0xb7866000, 10504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7866000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7705000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb77056c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7863000, 8192, PROT_READ) = 0
mprotect(0xb788c000, 4096, PROT_READ) = 0
munmap(0xb7869000, 16593) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb786d000
write(1, "10 \n"..., 410
) = 4
exit_group(0) = ?
вот вывод file:
Код: Выделить всё
./test_proj: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
напомню суть проблемы:
при отладке из под чистого gdb - отладчик не бегает по циклу, а один раз заходит а потом сразу выполняет следующую за циклом строку.
при выполнении отладки через нетбинс - отладчик после остановки на первом брекпоинте, начинает скакать по коду(в пошаговом режиме) хаотично.
запуск на выполнение без отладки в обоих случаях работает корректно.
-
- Сообщения: 6
- ОС: slackware 13.1
Re: отладчик gdb
может подскажете где еще поспрашивать? проблема реально мне еще крови попьет.
-
- Сообщения: 2041
- Статус: ☮ PEACE ☮
- ОС: открытая и свободная
Re: отладчик gdb
Тем не менее, последняя инструкция в выводе strace именно write-вывод на первый деструктор (т.е. на stdout) "10 \n", что и должно быть.
Кстати, и какая это строка, следующая за циклом? Т.е. какое значение j передается?
Вот мой вывод strace:
Код: Выделить всё
> strace ./test.c
execve("./test.c", ["./test.c"], [/* 97 vars */]) = 0
brk(0) = 0x2338000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffc3e9ab000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=150582, ...}) = 0
mmap(NULL, 150582, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffc3e986000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\34\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1915142, ...}) = 0
mmap(NULL, 3787328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffc3e3ef000
mprotect(0x7ffc3e583000, 2093056, PROT_NONE) = 0
mmap(0x7ffc3e782000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x193000) = 0x7ffc3e782000
mmap(0x7ffc3e788000, 14912, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffc3e788000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffc3e985000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffc3e984000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffc3e983000
arch_prctl(ARCH_SET_FS, 0x7ffc3e984700) = 0
mprotect(0x7ffc3e782000, 16384, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ) = 0
mprotect(0x7ffc3e9ac000, 4096, PROT_READ) = 0
munmap(0x7ffc3e986000, 150582) = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffc3e9aa000
write(1, "10 \n", 410
) = 4
exit_group(0) = ?
+++ exited with 0 +++
Вот код:
Код: Выделить всё
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char** argv)
{
int i, j=0;
for(i=0; i<10; i++)
j++;
printf("%d \n",j);
return (EXIT_SUCCESS);
}
Сеанс gdb:
Код: Выделить всё
alex@pizza:~/code/C> gcc -g test.c -o test
alex@pizza:~/code/C> gdb ./test
GNU gdb (GDB; openSUSE Factory) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...done.
(gdb) b main
Breakpoint 1 at 0x40056c: file test.c, line 6.
(gdb) r
Starting program: /home/alex/code/C/test
Breakpoint 1, main (argc=1, argv=0x7fffffffde68) at test.c:6
6 int i, j=0;
(gdb) n
7 for(i=0; i<10; i++)
(gdb) n
8 j++;
(gdb) n
7 for(i=0; i<10; i++)
(gdb) n
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
8 j++;
(gdb)
7 for(i=0; i<10; i++)
(gdb)
10 printf("%d \n",j);
(gdb)
10
11 return (EXIT_SUCCESS);
(gdb)
12 }
(gdb)
__libc_start_main (main=0x40055d <main>, argc=1, argv=0x7fffffffde68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffde58) at libc-start.c:323
323 libc-start.c: No such file or directory.
(gdb)
[Inferior 1 (process 4428) exited normally]
Labor omnia vincit
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
-
- Сообщения: 2041
- Статус: ☮ PEACE ☮
- ОС: открытая и свободная
Re: отладчик gdb
Ну что ж Вы такое советуете-то? Во-первых, у нас самих тут C-шников хватает, во-вторых, LOR абсолютно немодерируемый форум, со всеми вытекающими.
Вы используете команду s, т.е. отладчик заходит в каждую промежуточную библиотеку. Вы сначала выложите обычный n-пробег, как я показал выше. Как только увидим на каком именно месте он запнулся, можем уже после зайти в конкретные библиотеки.
Labor omnia vincit
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” (Brian Kernighan)
-
- Сообщения: 6
- ОС: slackware 13.1
Re: отладчик gdb
кароч, не стал я заморачиватся, собрал на другой версии ядра, все заработало. некогда ковырять, сорри что потерялся, командировки.