| 1 |
hi, |
| 2 |
|
| 3 |
|
| 4 |
> also, hier der kritische Bereich: |
| 5 |
> ---snip |
| 6 |
> pushf |
| 7 |
> |
| 8 |
> pushf |
| 9 |
> pop ax |
| 10 |
> |
| 11 |
> popf |
| 12 |
> ---snip |
| 13 |
|
| 14 |
sieht bei mir so aus (athlon xp 2000): |
| 15 |
|
| 16 |
twist@xen ~/tmp $ objdump -S -Mintel main |
| 17 |
|
| 18 |
main: file format elf32-i386 |
| 19 |
|
| 20 |
Disassembly of section .text: |
| 21 |
|
| 22 |
080480a0 <.text>: |
| 23 |
80480a0: bc c0 91 04 08 mov esp,0x80491c0 |
| 24 |
80480a5: 66 31 d2 xor dx,dx |
| 25 |
80480a8: 66 81 fa 00 00 cmp dx,0x0 |
| 26 |
80480ad: 9c pushf |
| 27 |
80480ae: 9c pushf |
| 28 |
80480af: 66 58 pop ax |
| 29 |
80480b1: 9d popf |
| 30 |
80480b2: b8 01 00 00 00 mov eax,0x1 |
| 31 |
80480b7: bb 00 00 00 00 mov ebx,0x0 |
| 32 |
80480bc: cd 80 int 0x80 |
| 33 |
|
| 34 |
|
| 35 |
> |
| 36 |
> Erzeugt hier folgenden Code: 9c 9c 68 58 9d |
| 37 |
> |
| 38 |
> Das Problem: die pushf's schieben 32bit auf den Stack, verringern also |
| 39 |
> den Stack-Pointer jeweils um 4 (256 Byte sind für dieses Programm sehr |
| 40 |
> großzügig!). D.h., relativ sind wir bei -8. Dann kommt "pop ax", man |
| 41 |
> beachte: "68" im Code, also Wechsel zu 16bit. D.h., der Stackpointer |
| 42 |
> erhöht sich nur um zwei. Mit dem nächsten popf ziehst du dann die |
| 43 |
> oberen 16bit der Flags in die unteren und umgekehrt und hinterläßt |
| 44 |
> außerdem noch zwei Bytes auf dem Stack. |
| 45 |
|
| 46 |
darüber hab ich auch schon lange gegrübelt. meine docu sagt aber: |
| 47 |
|
| 48 |
PUSHF/PUSHFD |
| 49 |
|
| 50 |
Pushes the flags register onto the stack. PUSHF always pushes the 16-bit |
| 51 |
flags register. On the 80386/486, use PUSHFD to push the 32-bit flags |
| 52 |
register. |
| 53 |
|
| 54 |
und die dinger werden mit 10011100 codiert, also 0x9c. anscheinend ist das |
| 55 |
abhängig davon, ob die kiste im protected mode läuft. das würde auch |
| 56 |
abwärtskompatibilität erklären. |
| 57 |
|
| 58 |
> |
| 59 |
> Da du sonst ja auch 32bit-Register benutzt, würde ich schlicht dazu |
| 60 |
> raten, "pop eax" zu nehmen. |
| 61 |
> |
| 62 |
> Dass das dann mit dem cmp zusammenhängt, liegt wohl daran, dass hier |
| 63 |
> das zero-Flag entweder gesetzt sind oder nicht. |
| 64 |
|
| 65 |
das ding wird intern doch so ausgewertet: |
| 66 |
|
| 67 |
cmp op1, op2 |
| 68 |
|
| 69 |
tmp = op1 - op2 |
| 70 |
|
| 71 |
die flags werden tmp entsprechend gesetzt. |
| 72 |
--> damit ist das zero-flag immer gleich (bei cmp 0, 4 und cmp 0, 8). |
| 73 |
|
| 74 |
> |
| 75 |
> Tricks mit pushf/popf waren übrigens auch mal ein probates Mittel, |
| 76 |
> herauszufinden, auf welcher i32-Architektur ein Programm läuft. Ich bin |
| 77 |
> mir also recht sicher, dass dokumentiert ist, was hier passiert. |
| 78 |
|
| 79 |
ja, stimmt. aber dennoch darf mir ein fehlerhaftes programm nicht den |
| 80 |
x-server unterm a..... wegballern. |
| 81 |
|
| 82 |
twist |
| 83 |
|
| 84 |
-- |
| 85 |
gentoo-user-de@g.o mailing list |
Archives