Czy jest możliwe sprawdzenie wartości zwracanej funkcji w gdb przy założeniu, że zwracana wartość to , a nie przypisana do zmiennej?Jak sprawdzić zwracaną wartość funkcji w GDB?
Odpowiedz
sobie wyobrazić, że są lepsze sposoby, aby to zrobić, ale komenda finish wykonuje aż bieżąca ramka stosu jest zdejmowana i drukuje wartości zwracanej - dany program
int fun() {
return 42;
}
int main(int argc, char *v[]) {
fun();
return 0;
}
można debugować go jako taki -
(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)
Tak, wystarczy przejrzeć rejestr EAX
, wpisując: print $eax
. W przypadku większości funkcji wartość zwracana jest przechowywana w tym rejestrze, nawet jeśli nie jest używana.
Wyjątki od tej zasady są funkcjami powracający typy większy niż 32 bitów, a zwłaszcza 64-bitowych liczb całkowitych (long long
), double
S i structs
lub classes
.
Innym wyjątkiem jest sytuacja, gdy nie używasz architektury Intel. W takim przypadku musisz dowiedzieć się, który rejestr jest używany, jeśli taki istnieje.
Nie używanie komputera intel, działającego na sparc. g0 to miejsce, w którym przechowywana jest wartość zwracana, ale chciałbym coś niezależnego od architektury .. – fuad
Dzięki za wyjaśnienia; Zakładałem, że używasz x86. Ale jeśli nie zamierzasz tworzyć skryptów GDB na wielu architekturach, nie widzę powodu, aby nie używać "print $ g0", który nie ma żadnych skutków ubocznych (w przeciwieństwie do innych odpowiedzi). –
Pewnie. Niestety, jest to o0, a nie g0. Zarejestruj g0 jest zawsze 0. – fuad
Oto jak to zrobić bez symboli.
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
Formatowanie trochę pomieszane tam zwrócić uwagę na użycie „info ramki” do wglądu ramek i „ramki #”, aby poruszać się kontekst innym kontekście (w górę iw dół stosu)
BT również show jest skróconą stertą, aby pomóc.
Świetna odpowiedź koleś. Używałem "powrotu", który w rzeczywistości wymusza powrót z ramki (oczywiście bez wartości zwrotnej) i nie mógł wyliczyć, co było nie tak: P –
Tak, jeden z najbardziej przydatnych trików gdb, których się nauczyłem –