NASM non conosce il registro IP??? O_o [Archivio]

View Full Version : NASM non conosce il registro IP??? O_o

71104

24-07-2005, 22:30

scusate, sono assai niubbone col NASM; ho scritto un codice semplicissimo:
[bits 16]
call cs:ip

eppure mi da un errore: "symbol 'ip' undefined"!!! :confused:
ma mi sbaglio io o sugli x86 l'instruction pointer si chiama IP??? O_o
:mc:

71104

24-07-2005, 22:31

ho anche provato con le parentesi quadre in questi due modi:
call cs:[ip] che è l'uso più frequente, e:
call [cs:ip] ma con entrambi mi da lo stesso errore!!!
:mc:

cionci

25-07-2005, 00:00

Sinceramente non ho mai visto un accesso diretto di questo tipo ad IP... Poi che senso ha se sei già nel CS ? Se non sei nel CS, ha già più senso...

71104

25-07-2005, 00:13

no dai cavolo, deve essere possibile accedere all'instruction pointer... l'intenzione era proprio quella di chiamare l'istruzione corrente al solo fine di mettere nello stack cs ed ip; ad essere precisi non so bene se quel codice chiama se stesso o l'istruzione successiva... non so se IP punta all'istruzione corrente o alla prossima, comunque si trattava solo di una prova. come mi spieghi che non mi funziona nemmeno questo codice?

[bits 16]
mov ax,ip

sempre lo stesso errore naturalmente... :(

71104

25-07-2005, 00:15

hmmm, forse però ripensandoci l'accesso al registro (e)ip non è proprio possibile... mi sembra strano ma in effetti potrebbe essere così...
in tal caso penso che risolverò così:

[bits 16]
call here
here:
pop ax
pop dx

così mi dovrei ritrovare cs ed ip in dx e ax (rispettivamente se non erro), solo che devo assicurarmi che il call sia far e non near; come posso fare?

cionci

25-07-2005, 00:16

ilsensine

25-07-2005, 08:20

Ripeto...che io sappia le uniche istruzioni che possono modificare Ip sono le varie jmp e la call...
...e ret.
Sui nostri fornelletti non si può accedere a ip come un registro normale.
Altre architetture (ad es. gli ARM) non hanno questa limitazione.

repne scasb

25-07-2005, 09:30

...e ret.
In assembly per 80x86 qualsiasi istruzione incrementa il registro E(IP) della lunghezza dell'opcode dell'istruzione stessa. Fanno eccezione, coma gia' detto le istruzioni: call, jmp e ret. Ma anche:

int
int3
into
iret
jcc (take)
loop
loope (take)
loopne (take)

+le eccezioni. Tali istruzioni permetto di modificare E(IP) aldila' della distanza dell'opcode stesso. Nel caso si voglia conoscere il contenuto del registro IP il codice classico (16-bit) e' il seguente:

call $+3
pop ax
sub ax,3h

In AX si ha il registro IP prima di eseguire la CALL. Esiste comunque un altro metodo per leggere il registro E(IP), tramite l'istruzione non documentata LOADALL (0Fh,5h). Eseguendo tale opcode in modalita' reale, all'indirizzo 80h:0h sara' caricata una tabella al cui offset 1Ah sara' leggibile il registro IP. Su processori di classe 386 e' disponibile una LOADALL piu' dettagliata (0Fh,7h), in questo caso la tabella non viene caricata all'indirizzo 80:0 ma all'indirizzo specificato in ES:EDI, il rigistro EIP sara' visibile all'offset 8h.

ilsensine

25-07-2005, 09:37

In AX si ha il registro IP prima di eseguire la CALL. Esiste comunque un altro metodo per leggere il registro E(IP), tramite l'istruzione non documentata LOADALL (0Fh,5h). Eseguendo tale opcode in modalita' reale, all'indirizzo 80h:0h sara' caricata una tabella al cui offset 1Ah sara' leggibile il registro IP. Su processori di classe 386 e' disponibile una LOADALL piu' dettagliata (0Fh,7h), in questo caso la tabella non viene caricata all'indirizzo 80:0 ma all'indirizzo specificato in ES:EDI, il rigistro EIP sara' visibile all'offset 8h.
Interessante, non lo sapevo.
Sai anche qualcosa sulla portabilità di questa funzione? Voglio dire, è rimasta inalterata dal 386 al P4 (e magari introdotta anche sugli AMD/Cyrix/Trasmeta ecc.)? Essendo "non documentata", potrebbe sparire o cambiare senza preavviso...

repne scasb

25-07-2005, 09:53

Interessante, non lo sapevo.
Sai anche qualcosa sulla portabilità di questa funzione? Voglio dire, è rimasta inalterata dal 386 al P4 (e magari introdotta anche sugli AMD/Cyrix/Trasmeta ecc.)? Essendo "non documentata", potrebbe sparire o cambiare senza preavviso...

0Fh,5h - Esiste dalla CPU 80286 in poi. (Questa istruzione e' definita a pagina 15 dell'ICD (Intel Confidential Document).
0Fh,7h (PM) - Esiste dalla CPU 80386 in poi.

Sulla portabilita' di tale istruzione ti posso dire che ancora oggi Windows XP quando apre una sessione del Prompt del Comandi in Virtual8086 lascia un buco di 102 bytes all'indirizzo 80:0. In piu' LOADALL386(0Fh,7h) e' utilizzata sicuramente dal sistema operativo OS/2, e anche dal BIOS Award Medallion 6.0 (disassemblato personalmente). 0Fh,5h e' utilizzata da Windows e ancora oggi se ne trova traccia in Kernel32.dll di WindowsXP. LOADALL e' un istruzione assai "potente" che riporta 102 byte di informazioni sullo stato del processore (286) e fino a 204 byte nel caso 386.

okay

25-07-2005, 13:54

0Fh,5h - Esiste dalla CPU 80286 in poi. (Questa istruzione e' definita a pagina 15 dell'ICD (Intel Confidential Document).
0Fh,7h (PM) - Esiste dalla CPU 80386 in poi.

Sulla portabilita' di tale istruzione ti posso dire che ancora oggi Windows XP quando apre una sessione del Prompt del Comandi in Virtual8086 lascia un buco di 102 bytes all'indirizzo 80:0. In piu' LOADALL386(0Fh,7h) e' utilizzata sicuramente dal sistema operativo OS/2, e anche dal BIOS Award Medallion 6.0 (disassemblato personalmente). 0Fh,5h e' utilizzata da Windows e ancora oggi se ne trova traccia in Kernel32.dll di WindowsXP. LOADALL e' un istruzione assai "potente" che riporta 102 byte di informazioni sullo stato del processore (286) e fino a 204 byte nel caso 386.

repne scasb (ti adoro.....)
sei....... sei spettacolare.
E' un piacere leggerti

ciao da okay