Как проверить возвращаемое значение функции в GDB?
Можно ли проверить возвращаемое значение функции в GDB, предполагая, что возвращаемое значение нет присвоено переменной?
Ответы 3
Да, просто проверьте регистр EAX, набрав print $eax. Для большинства функций возвращаемое значение сохраняется в этом регистре, даже если оно не используется.
Исключением являются функции, возвращающие типы больше 32 бит, в частности 64-битные целые числа (long long), doubles и structs или classes.
Другое исключение - если вы не используете архитектуру Intel. В этом случае вам нужно будет выяснить, какой регистр используется, если таковой имеется.
Благодарю за разъяснение; Я предполагал, что вы используете x86. Но если вы не собираетесь писать сценарии GDB для нескольких архитектур, я не вижу веской причины не использовать «print $ g0», который не имеет побочных эффектов (в отличие от других ответов).
Конечно. К сожалению, это o0, а не g0. Регистр g0 всегда равен 0.
Я предполагаю, что есть более эффективные способы сделать это, но команда Конец выполняется до тех пор, пока текущий кадр стека не выскочит и не распечатает возвращаемое значение - учитывая программу
int fun() {
return 42;
}
int main( int argc, char *v[] ) {
fun();
return 0;
}
Вы можете отладить его как таковой -
(gdb) r
Starting program: /usr/home/hark/a.out
Breakpoint 1, fun () at test.c:2
2 return 42;
(gdb) finish
Run till exit from #0 fun () at test.c:2
main () at test.c:7
7 return 0;
Value returned is $1 = 42
(gdb)
Команда finish может быть сокращена до fin. НЕ используйте команду f, которая является сокращением команды frame!
Отличный ответ, чувак. Я использовал "return", который на самом деле принудительно возвращается из кадра (очевидно, без возвращаемого значения), и не мог понять, что было не так: P
Могу б дурацкий вопрос А что, если функция не имеет возвращаемого значения?
@hark, как это сделать, когда gdb не может войти в функцию, например, когда символы отладки для конкретной библиотеки недоступны?
Вот как это сделать без символов.
gdb ls
This GDB was configured as "ppc64-yellowdog-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) break __libc_start_main
Breakpoint 1 at 0x10013cb0
(gdb) r
Starting program: /bin/ls
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Breakpoint 1 at 0xfdfed3c
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 4160418656 (LWP 10650)]
(no debugging symbols found)
(no debugging symbols found)
[Switching to Thread 4160418656 (LWP 10650)]
Breakpoint 1, 0x0fdfed3c in __libc_start_main () from /lib/libc.so.6
(gdb) info frame
Stack level 0, frame at 0xffd719a0:
pc = 0xfdfed3c in __libc_start_main; saved pc 0x0
called by frame at 0x0
Arglist at 0xffd71970, args:
Locals at 0xffd71970, Previous frame's sp is 0xffd719a0
Saved registers:
r24 at 0xffd71980, r25 at 0xffd71984, r26 at 0xffd71988, r27 at 0xffd7198c,
r28 at 0xffd71990, r29 at 0xffd71994, r30 at 0xffd71998, r31 at 0xffd7199c,
pc at 0xffd719a4, lr at 0xffd719a4
(gdb) frame 0
#0 0x0fdfed3c in __libc_start_main () from /lib/libc.so.6
(gdb) info fr
Stack level 0, frame at 0xffd719a0:
pc = 0xfdfed3c in __libc_start_main; saved pc 0x0
called by frame at 0x0
Arglist at 0xffd71970, args:
Locals at 0xffd71970, Previous frame's sp is 0xffd719a0
Saved registers:
r24 at 0xffd71980, r25 at 0xffd71984, r26 at 0xffd71988, r27 at 0xffd7198c,
r28 at 0xffd71990, r29 at 0xffd71994, r30 at 0xffd71998, r31 at 0xffd7199c,
pc at 0xffd719a4, lr at 0xffd719a4
Форматирование там немного запуталось, обратите внимание на использование «информационного фрейма» для проверки фреймов и «фрейма №» для перехода вашего контекста в другой контекст (вверх и вниз по стеку).
bt также показывает сокращенный стек, чтобы помочь.
Не использую машину Intel, работающую на sparc. g0 - это место, где хранится возвращаемое значение, но я бы хотел что-то независимое от архитектуры ..