Linux-Kernel header.S Quelle, warum _end + 3 benötigt, wenn BSS Nullsetzen?

Question

in dem Baum Linux Quelle die Datei arch/x86/boot/header.S x86-Code ähnlich wie dies den BSS Abschnitt vor main löschen hat dazu aufgerufen:

... 
# Zero the bss 
    movw $__bss_start, %di 
    movw $_end+3, %cx 
    xorl %eax, %eax 
    subw %di, %cx 
    shrw $2, %cx 
    rep; stosl 
... 

Warum hat die _end Adresse 3 hinzugefügt? Warum nicht movw $_end, %cx anstelle von movw $_end+3, %cx?

Answer 1

Hätte der Code gelöscht BSS Abschnitt by Byte movw $_end, %cx würde ausreichen. Dieser Code löscht jedoch nicht die BSS mit STOSB sie verwenden STOSL. Es ist im Allgemeinen effizienter, 32 Bits gleichzeitig als 8 Bits zu speichern.

STOSL speichert EAX genug Zeiten (die auf Null mit xorl %eax, %eax gesetzt ist), um den gesamten Bereich der löschen BSS 0. Die 3 stellt sicher, dass, wenn die Länge des BSS Abschnitt ($ _end - $ __ bss_start) ist nicht durch 4 teilbar, so dass die Anzahl der DWORD benötigten Daten zum Aufräumen aufgerundet wird. Wenn diese Aufrundung nicht auftritt, werden die letzten Bytes möglicherweise nicht gelöscht, wenn die Größe nicht durch 4 teilbar ist.

Die Berechnung hier getan wird, wird davon ausgegangen __bss_start ein Zeiger auf den Anfang des BSS-Segment ist, und dass _end ist ein Zeiger auf das Ende des BSS. Die Gleichung, die die Anzahl von 32-Bit-DWORD s zu berechnen ist effektiv zu löschen:

NUMDWORDS=(_end+3-__bss_start) >> 2 

Die shrw $2, %cx (>>2 bei der Berechnung) ist ganzzahligen Division durch 4, wobei das Ergebnis immer nach unten abgerundet ist. Wir addieren +3 zu der Anzahl von Bytes, so dass, wenn die Division durch 4 gemacht wird, es effektiv auf die nächste Zahl von DWORD s aufrundet. Dieser Wert wird dann als die Anzahl der DWORD s STOSL wird auf Null gesetzt.