🚀 go-pugleaf

Użytkownik "Wiktor S." napisał w wiadomości...
> Mam problem z przełączaniem zadań za pomocą instrukcji CALL i IRET.
> Przełączanie poprzez JMP działa prawidłowo, tak samo wywołanie zadania
> instrukcją CALL. Niestety, próba powrotu przez IRET kończy się
> wyjątkiem.

I prawidlowo, instrukcja iret sluzy do powrotu z procedury obslugi
przerwania, w twoim przypadku powinno byc chyba po prostu ret.

> Gdy nie ma błędu program powinien wyświetlić FFFF i gwiazdki.
> W przypadku wyjątku wyświetla:
>
> nr_wyjątku  CS:EIP | EFLAGS | kod_błędu

To napisz chociaz konkretnie co wyswietla, jak masz podany
cs:ip to mozesz pokusic sie o deasemblacje kodu i sprawdzenie
na jakiej instrukcji sie wyklada.

PS.
Po co robic takie obejscia w stylu db 9ah..., powinno zadzialac
po prostu call 64:0 albo jmp 64:0,
a do testowania bardziej sie chyba nada bochs,
http://bochs.sourceforge.net/

-- 
Pozdrawiam
Lopez

>> Mam problem z przełączaniem zadań za pomocą instrukcji CALL i IRET.
>> Przełączanie poprzez JMP działa prawidłowo, tak samo wywołanie
>> zadania instrukcją CALL. Niestety, próba powrotu przez IRET kończy
>> się wyjątkiem.

> I prawidlowo, instrukcja iret sluzy do powrotu z procedury obslugi
> przerwania, w twoim przypadku powinno byc chyba po prostu ret.

Nie, Zgodnie z dokumentacją, jeśli przez call wywołano zadanie, iret 
powróci do poprzedniego.

> To napisz chociaz konkretnie co wyswietla, jak masz podany
> cs:ip to mozesz pokusic sie o deasemblacje kodu i sprawdzenie
> na jakiej instrukcji sie wyklada.

Wyjątek 0D na instrukcji iret.

> Po co robic takie obejscia w stylu db 9ah...,

Bo tasm (w przeciwieństwie do nasma) jest porąbany i wszelkie 
kombinacje z "call 64:0", call [64:0], call far ..., call dword ptr 
...
itd. kończą się albo komunikatem "illegal immediate", albo "near call 
to different cs", albo inną instrukcją, niż o którą chodzi.
Niestety, jestem tu skazany na tasma.

> powinno zadzialac po prostu call 64:0 albo jmp 64:0,

Nie przechodzi.

> a do testowania bardziej sie chyba nada bochs,
> http://bochs.sourceforge.net/

Dlaczego bardziej? Bochs jest dużo wolniejszy, bo emuluje procka 
programowo.

-- 
Azarien

Grzeczna odpowiedź do listu Wielce Szanownej Pani / Szanownego Pana
„Wiktor S.”.

>>	To napisz chociaz konkretnie co wyswietla, jak masz podany cs:ip to
>>	mozesz pokusic sie o deasemblacje kodu i sprawdzenie na jakiej
>>	instrukcji sie wyklada.
>	Wyjątek 0D na instrukcji iret.
Czyli #GP, tak?
Możliwe, że stos jest uszkodzony, czy też nie są odpowiednie poziomy
uprzywilejowania, albo zadanie zajęte :) może flaga NT wyczyszczona.
Super skomplikowane wyjaśnienie, które wszystko opisuje jest w drugim
tomie podręcznika procesora - opis instrukcji IRET - gdzie jest są
również wymienione przypadki wystąpienia #GP(0) i #GP(selector).

>>	Po co robic takie obejscia w stylu db 9ah...,
>	Bo tasm (w przeciwieństwie do nasma) jest porąbany i wszelkie kombinacje
>	z "call 64:0", call [64:0], call far ..., call dword ptr ...
>	itd. kończą się albo komunikatem "illegal immediate", albo "near call
>	to different cs", albo inną instrukcją, niż o którą chodzi. Niestety,
>	jestem tu skazany na tasma.
Możliwe, że tutaj podane rozwiązenie będzie skuteczne:
http://community.borland.com/article/0,1410,19029,0.html

Wasz
-- 
: qo   |)     =@=N%_g=v=a=g_ed_e=c()=d=8= %IGn@8're: w8in ad
:    _x/ ,     H'%'a'h4'HA.XO'Xo'xo'xO.R %expo1ited: *-1 teh
:    |    ng  __%-- __ -- __ -- __ -- __%/by$qVerCo: &GooMee
^.__ -- __ -- % dbqr74oh4ekrbrgz.onion %/^v^'^ww^v^;_<E-O-F>

Wiktor S. napisał(a):
>>> Mam problem z przełączaniem zadań za pomocą instrukcji CALL i IRET.
>>> Przełączanie poprzez JMP działa prawidłowo, tak samo wywołanie
>>> zadania instrukcją CALL. Niestety, próba powrotu przez IRET kończy
>>> się wyjątkiem.
> 
> 
>> I prawidlowo, instrukcja iret sluzy do powrotu z procedury obslugi
>> przerwania, w twoim przypadku powinno byc chyba po prostu ret.
> 
> 
> Nie, Zgodnie z dokumentacją, jeśli przez call wywołano zadanie, iret 
> powróci do poprzedniego.

Instrukcja ret spowoduje powrot do poprzedniego TSS tylko
wtedy gdy jest to zadanie zagniezdzone, czyli jest ustawiony
bit NT rejestru eflags. W przeciwnym wypadku adres powrotu
jest pobierany ze stosu. Nalezy wiedziec ze przy JMP/CALL do
TSS adres powrotu nie jest zachowywany na stosie zadania.
Podobnie dziala iret z ta roznica ze przywraca takze stan
rejestru flag, i jest przeznaczony do powrotu z procedur
wywolanych przez tablice IDT, czyli przerwania i wyjatki.


>> To napisz chociaz konkretnie co wyswietla, jak masz podany
>> cs:ip to mozesz pokusic sie o deasemblacje kodu i sprawdzenie
>> na jakiej instrukcji sie wyklada.
> 
> 
> Wyjątek 0D na instrukcji iret.

W twoim przypadku nie wiadomo co sie znajduje na szczycie
stosu wiec powrot nastepuje w 'kosmos', stad wyjatek #GP.
W tym wypadku proponuje Ci zamiast iret, call do dowolnie
wybranego TSS, tak jak to rozwiazales z JMP.

>> Po co robic takie obejscia w stylu db 9ah...,
> 
> Bo tasm (w przeciwieństwie do nasma) jest porąbany i wszelkie kombinacje 
> z "call 64:0", call [64:0], call far ..., call dword ptr ...
> itd. kończą się albo komunikatem "illegal immediate", albo "near call to 
> different cs", albo inną instrukcją, niż o którą chodzi.
> Niestety, jestem tu skazany na tasma.

Ja juz dawno porzucilem tasma, glownie dlatego, ze praktycznie
nie jest tam mozliwe legalne mieszanie kodu 16 i 32 bitowego.
Poczatkowo na rzecz nasm'a, potem byl fasm, a obecnie at&t.

>> a do testowania bardziej sie chyba nada bochs,
>> http://bochs.sourceforge.net/
> 
> Dlaczego bardziej? Bochs jest dużo wolniejszy, bo emuluje procka 
> programowo.

Przy takim przykladzie raczej nie zauwazysz wplywu emulacji
na szybkosc dzialania twojego programu. A na dodatek
masz tam wbudowany debugger, ktory pozwoli Ci obejrzec
stan procesora w dowolnie wybranym momencie.
No i w przeciwinstwie do M$ VirtualPC jest darmowy.


-- 
Pozdrawiam
Lopez

> Instrukcja ret spowoduje powrot do poprzedniego TSS tylko
> wtedy gdy jest to zadanie zagniezdzone, czyli jest ustawiony
> bit NT rejestru eflags.

Ale bit ten ustawia chyba właśnie call do zadania?
(opieram się na podręczniku AMD64 Architecture Programmer's Manual)

>>> Po co robic takie obejscia w stylu db 9ah...,

>> Bo tasm (w przeciwieństwie do nasma) jest porąbany

> Ja juz dawno porzucilem tasma,
> Poczatkowo na rzecz nasm'a, potem byl fasm, a obecnie at&t.

at&t jest straszne.
Pół biedy z tymi wszystkimi % i $, gorzej że kod trzeba się nauczyć 
czytać od tyłu ;-)

>>> a do testowania bardziej sie chyba nada bochs,
>>> http://bochs.sourceforge.net/

>> Dlaczego bardziej? Bochs jest dużo wolniejszy, bo emuluje procka
>> programowo.

> Przy takim przykladzie raczej nie zauwazysz wplywu emulacji
> na szybkosc dzialania twojego programu.

Ale zauważam przy pisaniu i kompilacji, a dla wygody wszystko robiłem 
pod VPC.

> No i w przeciwinstwie do M$ VirtualPC jest darmowy.

na VirtualPC mam licencję. Ale, ale -- właśnie widzę, że program 
odpalony na "na żywo" jak i pod Bochsem działa prawidłowo... czyli to 
nie ja tylko M$ coś schrzanił w emulatorze? :-/


-- 
Azarien

Użytkownik "Wiktor S." napisał w wiadomości...
> > Instrukcja ret spowoduje powrot do poprzedniego TSS tylko
> > wtedy gdy jest to zadanie zagniezdzone, czyli jest ustawiony
> > bit NT rejestru eflags.
>
> Ale bit ten ustawia chyba właśnie call do zadania?
> (opieram się na podręczniku AMD64 Architecture Programmer's Manual)

No wlasnie nie zawsze, kiedy to ma miejsce nie potrafie teraz dokladnie
powiedziec. Mozesz po bochsem to latwo sprawdzic, wystarczy ze zrobisz
sobie w odpowiednim momencie petle w programie, i po uruchomieniu
wyswietlisz stan rejestrow procesora.
Co do manuali do dobrze by bylo abys zdobyl wczesniejsze
wersje Intela. Jezeli dopiero poznajesz ta architekture latwiej bedzie Ci
w nich odnalezc najwazniejsze informacje, bez zastanawiania sie czy to
jakis zbedny do ficzer.

> >>> Po co robic takie obejscia w stylu db 9ah...,
>
> >> Bo tasm (w przeciwieństwie do nasma) jest porąbany
>
> > Ja juz dawno porzucilem tasma,
> > Poczatkowo na rzecz nasm'a, potem byl fasm, a obecnie at&t.
>
> at&t jest straszne.
> Pół biedy z tymi wszystkimi % i $, gorzej że kod trzeba się nauczyć
> czytać od tyłu ;-)

Trzeba byc elastycznym, jak sie zna kilka jezykow to jeden wiecej
nie robi roznicy, a na unixach to jest niestety standard.
Co prawda nasm i fasm tez dziala na linuxie, ale nasm niestety
nie jest juz rozwijany i obsluguje tylko x86, fasm dodatkowo x86-64.

> >>> a do testowania bardziej sie chyba nada bochs,
> >>> http://bochs.sourceforge.net/
>
> >> Dlaczego bardziej? Bochs jest dużo wolniejszy, bo emuluje procka
> >> programowo.
>
> > Przy takim przykladzie raczej nie zauwazysz wplywu emulacji
> > na szybkosc dzialania twojego programu.
>
> Ale zauważam przy pisaniu i kompilacji, a dla wygody wszystko robiłem
> pod VPC.
>
> > No i w przeciwinstwie do M$ VirtualPC jest darmowy.
>
> na VirtualPC mam licencję. Ale, ale -- właśnie widzę, że program
> odpalony na "na żywo" jak i pod Bochsem działa prawidłowo... czyli to
> nie ja tylko M$ coś schrzanił w emulatorze? :-/

Bo w VPC nie jest tak na prawde produktem stworzonym przez M$,
to po pierwsze, a po drugie nie jest emulatorem. Posiada on szereg
mechanizmow akceleracji, dzieki ktorym jest szybki, ale moze sie tez
zachowywac dziwnie. IMHO zarowno VPC jak i VMware nie nadaja
sie do testowania kodu na tak niskim poziomie. Poza Bochs'em
jest jeszcze qemu, podobno jest troche szybszy,
moze on Ci przypadnie do gustu.

-- 
Pozdrawiam
Lopez

On Mon, 30 Jan 2006 22:46:23 +0100, Wiktor S. wrote:

> at&t jest straszne.
> Pół biedy z tymi wszystkimi % i $, gorzej że kod trzeba się nauczyć 
> czytać od tyłu ;-)

A nie czasem właśnie Intel pisze od tyłu? :)

-- 
ダレック
takeda@IRCnet.EFnet, ICQ# 15827691, YahooIM: takeda64
http://ircwiki.takeda.tk - strona wiki poświęcona IRC

Użytkownik "Wiktor S." <wswiktorSP@Mpoczta.fm> napisał w wiadomości 
news:drjd1e$95k$1@news.onet.pl...
> Mam problem z przełączaniem zadań za pomocą instrukcji CALL i IRET.
> Przełączanie poprzez JMP działa prawidłowo, tak samo wywołanie zadania 
> instrukcją CALL. Niestety, próba powrotu przez IRET kończy się wyjątkiem.

jestem poczatkujacy w ASM i mam pytanie w zwiazku z tematem
dlaczego w procedurze uzywasz IRET, a nie samo RET? czym sie roznia te dwa 
powroty? moze jest to zalezne od asemblera? ja uzywam TASM.

dzieki i pozdrawiam

-- 
steensh 

steensh napisał(a):
> 
> Użytkownik "Wiktor S." <wswiktorSP@Mpoczta.fm> napisał w wiadomości
> news:drjd1e$95k$1@news.onet.pl...
>> Mam problem z przełączaniem zadań za pomocą instrukcji CALL i IRET.
>> Przełączanie poprzez JMP działa prawidłowo, tak samo wywołanie zadania
>> instrukcją CALL. Niestety, próba powrotu przez IRET kończy się wyjątkiem.
> 
> jestem poczatkujacy w ASM i mam pytanie w zwiazku z tematem
> dlaczego w procedurze uzywasz IRET, a nie samo RET? czym sie roznia te
> dwa powroty? moze jest to zalezne od asemblera? ja uzywam TASM.

 W normalnym świecie normalnych programów RET powraca do 16- lub
32-bitowego adresu zachowanego na stosie przez instrukcję CALL.
 RETF powraca do adresu zachowanego przez instrukcję CALL FAR, tj.
segment i adres w tymże segmencie.
 IRET (interrupt return) działa jak RETF, ale dodatkowo zdejmuje ze
stosu flagi procesora (EFLAGS), wkładane np. przez instrukcję INT (lub
przez procesor, gdy otrzyma przerwanie sprzętowe).

 Spójrz tu: http://rudy.mif.pg.gda.pl/~bogdro/dos/a_kurs02.htm - pod
koniec strony jest opisany stos oraz działanie instrukcji CALL, INT
oraz krótko RET, RETF, IRET.

 Natomiast w świecie trybu chronionego, o którym mowa w tym wątku,
wszystko się strasznie komplikuje. To, co robią te instrukcje nieco
się zmienia, bo wszystko zależy od tego, dokąd chcemy wrócić.
Sprawdzane są uprawnienia, typ "segmentu", do którego się odwołujemy.
Procedura w tym kodzie to nie jest zwykła procedura, tylko inne
"zadanie" (task), tak jak w wielozadaniowych, nowoczesnych systemach
operacyjnych. Jej wywołanie poprzez CALL może wyglądać normalnie, ale
procesor wykonuje wtedy o wiele więcej niż w normalnych CALLach w
normalnych programach. A powrót z innego zadania realizuje się właśnie
przez IRET.

-- 
Pozdrawiam, Bogdan                                  (Linux i FreeDOS)
Kurs assemblera x86 (DOS i Linuks): http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Forum o programowaniu:                     http://programista.xorg.pl

Witam!

>  Nie, zgodnie z dokumentacją, jeśli przez call
> wywołano zadanie, iret powróci do poprzedniego.

Ciekaw jestem z jaką dokumentacją jest to zgodne.
IRET służy do powrotu z przerwania (Interrupt RETurn),
natomiast RET powoduje powrót do następnej po call
inststukci, ale RET znajduje się w wywoływanej
procedurze i nie ma potrzeby umieszczania jej na zewnątrz.
Poza tym nie wiem jaką rolę miała by spełniać?
Jeśli chodzi o stos w powiązaniu z call:
- wywołanie wrzuca na stos adres powrotu
- RET zdejmuje ten adres ze stosu i tam wraca po
  wykonaniu procedury.
W takim przypadku nic złego nie może się dziać.
Sprawdź pod debuggerem czy w wywoływanej procedurze
nie znajdują się przypadkiem jakieś instrukcje
psujące ramkę stosu. To niestety zdarza się w
niedopracowanych funkcjach.


Pozdrawiam!


--
Remek

>>  Nie, zgodnie z dokumentacją, jeśli przez call
>> wywołano zadanie, iret powróci do poprzedniego.

> Ciekaw jestem z jaką dokumentacją jest to zgodne.

AMD64 Architecture Programmer's Manual, volume 2: System Programming, strona 
375:

"The hardware task-switch mechanism transfers program control to a new task 
when any of the following occur:
- A CALL or JMP instruction with a selector operand that references a task 
gate is executed. [...]
[...]
- An IRET is executed while the EFLAGS.NT bit is set to 1 [...]"

IA-32 Intel(R) Architecture Software Developer's Manual, volume 3: System 
Programming Guide, strona 6-3:

"Software or the processor can dispatch a task for execution in one of the 
following ways:
- A explicit call to a task with the CALL instruction.
- A explicit jump to a task with the JMP instruction.
[...]
- A return (initiated with an IRET instruction) when the NT flag in the 
EFLAGS register is set."

> IRET służy do powrotu z przerwania (Interrupt RETurn),
> natomiast RET powoduje powrót do następnej po call
> inststukci, ale RET znajduje się w wywoływanej
> procedurze i nie ma potrzeby umieszczania jej na zewnątrz.
> Poza tym nie wiem jaką rolę miała by spełniać?

Nie rozumiem, kto mówił o umieszczaniu RET-a na zewnątrz procedury?

> Jeśli chodzi o stos w powiązaniu z call:
> - wywołanie wrzuca na stos adres powrotu
> - RET zdejmuje ten adres ze stosu i tam wraca po
>  wykonaniu procedury.
> W takim przypadku nic złego nie może się dziać.
> Sprawdź pod debuggerem czy w wywoływanej procedurze
> nie znajdują się przypadkiem jakieś instrukcje
> psujące ramkę stosu. To niestety zdarza się w
> niedopracowanych funkcjach.

Jeżeli call powoduje przełączenie zadania, nie jest nic zapamiętywane na 
stosie, tylko w strukturze TSS zadania aktualnego, przechowującej stan 
procesora. Następnie odtwarzany jest stan wszystkich rejestrów z TSS nowego 
zadania. Tak więc jest to skok, ale z automatycznym zapamiętaniem i 
odtworzeniem wszystkich rejestrów. Po przełączeniu zadania możemy mieć już 
nawet zupełnie inny stos...

W każdym razie, program taki jak napisałem działa bez problemu na Athlonie 
1200, a nie działa tylko pod MS VirtualPC...


--
Azarien

Witam!

> jeśli przez call

Nie analizowałem dokładnie programu, tylko zmieniłem
jn.:

call:
 db 9Ah
 dw 0
 dw 64

.....................

task1 proc
 mov byte ptr es:[1000],'*'

    ret    ; call/iret - tu sie wysypie

 ;db 0EAh    ; jmp/jmp - a tu nie
 ;dw 0
 ;dw 56

task1 endp

I to działa, nie wysypuje się. Wyświetla inne
dane, ale pewnie tak ma być, jak pisałem nie
przyglądałem się dokładnie. Chodzi tylko o ret.


Pozdrawiam!

--
Remek

> Nie rozumiem, kto mówił o umieszczaniu RET-a na zewnątrz procedury?

Sorry!!

Nie wiem dlaczego doszedłem do takiego wniosku.
Musiałem pomylić z czymś innym.

Doszedłeś już przyczyny?

Piszę po przeczytaniu kilku następnych wypowiedzi.
Jedni piszą, że adres powrotu idzie przez stos
( wtym przypadku )inni wprost przeciwnie. Jak to
jest naprawdę? Może ktoś kompetenty napisać dokładnie?

Nie mogę obejrzeć w debuggerze, bo mój SoftIce
wywala się na 16 bitach, wadliwa wersja programu,
albo obsługa.

> Ciekaw jestem z jaką dokumentacją jest to zgodne.

> AMD64 Architecture Programmer's Manual, volume 2:
> System Programming, strona 375:

Mea culpa! Proszę o wybaczenie! Czasem piszę coś
zbyt pochopnie.

Pozdrawiam!

--
Remek

> Doszedłeś już przyczyny?

Błąd występuje tylko w M$ VPC, widocznie bug w programie... ostatecznie 
zmodyfikowałem kod tak, by nie wykonywać felernej instrukcji.

> Piszę po przeczytaniu kilku następnych wypowiedzi.
> Jedni piszą, że adres powrotu idzie przez stos
> ( wtym przypadku )inni wprost przeciwnie.

W przypadku CALL powodującego przełączenie zadania, "adres powrotu" jest 
zapisywany nie na stosie, a w bieżącym TSS (Task State Segment).
Adres powrotu zapisywany jest na stosie w przypadku CALL do podprogramu.

-- 
Azarien