Jak działa demontaż instrukcji ramienia "BL"?

'bl' lub oddziału z nauczaniem link jest niemal zawsze staje 0xebfffffeJak działa demontaż instrukcji ramienia "BL"?

Jednak procesor i binutils GNU objdump jakoś wiedzieć, gdzie rozgałęzia:

00000000 <init_module>: 
    0: e1a0c00d  mov  ip, sp 
    4: e92ddff0  push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc} 
    8: e24cb004  sub  fp, ip, #4 
    c: e24dd038  sub  sp, sp, #56  ; 0x38 
    10: ebfffffe  bl  0 <init_module> 
    14: e59f0640  ldr  r0, [pc, #1600] ; 65c <init_module+0x65c> 
    18: ebfffffe  bl  74 <init_module+0x74>

Jak wiedzą?

Źródło

2013-02-21 yanychar

Problem jest spowodowany faktem, że przyglądasz się dezasemblacji pliku obiektu, a nie końcowego pliku wykonywalnego lub obiektu udostępnionego.

Gdy asembler tworzy plik obiektowy, ostateczny adres celu bl nie jest jeszcze ustalony (zależy to od innych plików obiektów, które zostaną z nim powiązane). Tak więc asembler ustawia adres na 0, ale także dodaje relokację, która mówi linkerowi, gdzie ten bl ma przejść do końcowego pliku. (Możesz zobaczyć informacje o zmianie lokalizacji w objdump przez dodanie przełącznika -r).

Podczas łączenia łącznik przetwarza relokację, oblicza końcowy adres funkcji docelowej i łata instrukcję tak, aby adres docelowy był wyrównany. Jeśli zdemontujesz ostatni, połączony plik wykonywalny, zobaczysz inny kod operacji.

Źródło

2013-02-21 14:14:54

Dzięki (spasibo). Plik jest modułem jądra. Myślałem, że jest to końcowy, połączony plik wykonywalny, ale najwyraźniej tak nie jest. Przełącznik '-r' jest tym, czego szukałem. – yanychar

Jest częściowo połączone; importowane symbole jądra są rozwiązywane podczas ładowania przez program ładujący jądra. –

Jak działa demontaż instrukcji ramienia "BL"?

Odpowiedz

Powiązane problemy