2015-07-13 19 views
9

Na moim komputerze mam binaria aarch64, które jest statycznie skompilowane. Uruchomiłem go za pomocą qemu-aarch64-static z flagą -g 6566. W innym terminalu uruchamiam gdb-multiarch i łączę się jako target remote localhost:6566.Obsługa sygnałów za pomocą qemu-użytkownika

Oczekuję, że plik binarny podniesie sygnał, dla którego mam program obsługi zdefiniowany w pliku binarnym. Ustawiłem punkt przerwania w programie obsługi od wewnątrz gdb-multiarch po podłączeniu do pilota. Jednakże, gdy pojawia się sygnał, punkt przerwania nie jest trafiony w gb-multiarch. Zamiast tego, na terminalu, który uruchamia plik binarny, otrzymuję komunikat wzdłuż linii: -

[1]  + 8388 suspended (signal) qemu-aarch64-static -g 6566 ./testbinary 

Dlaczego tak się dzieje? Jak ustawić punkt przerwania w module obsługi i debugować go? Próbowałem SIGCHLD i SIGFPE.

+0

Co to jest sygnał, który chcesz przechwycić? 'SIGCHLD' i' SIGFPE' są tworzone w bardzo różnych warunkach, nie widzę, jak je wypróbowałeś, ponieważ nie ma między nimi żadnej relacji. Pokaż kod obsługi i sposób ich konfiguracji. –

+0

Próbowałem ich obu dla oddzielnych plików binarnych. W przypadku Binarnego SIGCHLD rozwidla się, rodzic wykonuje oczekiwanie. W przypadku SIGFPE wykonuję zamierzony podział przez 0. Operatory są dodawane jako sygnał (SIGCHLD, handler) lub sygnał (SIGFPE, handler). –

Odpowiedz

1

robiłem trochę R & D za odpowiedź i znaleźć następującą odpowiedź

„Wewnętrznie zły pamięć dostęp rezultat w wyjątku EXC_BAD_ACCESS Mach wysyłane do programu. Zwykle jest to tłumaczone na sygnał SIGBUS UNIX Jednak gdb przechwytuje wprost wyjątki Macha przed translacją sygnału.Odpowiedź, by przed uruchomieniem programu dać gdb zestaw poleceń dont-handle-bad-access 1. Następnie wykorzystywany jest normalny mechanizm, a punkty przerwania wewnątrz programu obsługi sygnału są zaszczycony."

Link jest gdb: set a breakpoint for a SIGBUS handler To może pomóc, uznając, że qemu nie zmienia funkcjonalność operacji bazowych

2

To działa na mnie z niedawnym QEMU:

$ cat sig.c 

#include <stdlib.h> 
#include <signal.h> 
#include <stdio.h> 

void handler(int sig) { 
    printf("In signal handler, signal %d\n", sig); 
    return; 
} 

int main(void) { 
    printf("hello world\n"); 
    signal(SIGUSR1, handler); 
    raise(SIGUSR1); 
    printf("done\n"); 
    return 0; 
} 

$ aarch64-linux-gnu-gcc -g -Wall -o sig sig.c -static 

$ qemu-aarch64 -g 6566 ./sig 

a potem w innym oknie :

$ gdb-multiarch 
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 
[etc] 
(gdb) set arch aarch64 
The target architecture is assumed to be aarch64 
(gdb) file /tmp/sigs/sig 
Reading symbols from /tmp/sigs/sig...done. 
(gdb) target remote :6566 
Remote debugging using :6566 
0x0000000000400c98 in _start() 
(gdb) break handler 
Breakpoint 1 at 0x400e44: file sig.c, line 6. 
(gdb) c 
Continuing. 

Program received signal SIGUSR1, User defined signal 1. 
0x0000000000405c68 in raise() 
(gdb) c 
Continuing. 

Breakpoint 1, handler (sig=10) at sig.c:6 
6  printf("In signal handler, signal %d\n", sig); 
(gdb) 

Jak widać, gdb uzyskuje kontrolę zarówno natychmiast proces odbiera sygnał, a następnie zysk, gdy trafimy w punkt przerwania dla funkcji obsługi.

Nałożenie (całkowite) dzielenie przez zero nie jest niezawodnym sposobem na sprowokowanie sygnału. Jest to niezdefiniowane zachowanie w C, a implementacja jest darmowa, aby wykonać najwygodniejszą rzecz. Na x86 zwykle powoduje to SIGFPE. W ARM zwykle można stwierdzić, że wynik wynosi zero, a wykonanie będzie kontynuowane bez sygnału. (Jest to manifestacja różnych zachowań podstawowych instrukcji sprzętowych dotyczących podziału między dwiema architekturami.)

Powiązane problemy