Пользуется ли винда LDT?

Бсод не бсод, но на #GP ты здесь нарвешься

 

Intel Software Developers Manual, 6.3 - Task Switching

The processor transfers execution to another task in one of four cases:
• The current program, task, or procedure executes a JMP or CALL instruction to a
TSS descriptor in the GDT.
• The current program, task, or procedure executes a JMP or CALL instruction to a
task-gate descriptor in the GDT or the current LDT.
• An interrupt or exception vector points to a task-gate descriptor in the IDT.
• The current task executes an IRET when the NT flag in the EFLAGS register is set.

Я говорил про четвёртый вариант. Откуда GP#?
Главное выставить бит Nested Task в EFLAGS и ссылку на предыдущую задачу в своём TSS прописать.

 

Great
Я извеняюсь конечно, но ты что слепой.. чётко сказано:

 

Clerk - ты за своими глазами следи.
Ответ был непосредственно на предыдущий пост:

Вопрос - какими командами переключаются задачи.
Где хоть слово про Win?

 

cppasm
Автор задал вопрос:

Задачи переключаются програмно, переход на новую задачу выполняется в Kei386EoiHelper(), задача не корректна пока формируется её контекст(выполняется загрузка трап-фрейма), после этого инструкция Iret загрузит селектор кодового сегмента, что может считаться началом исполнения новой задачи.

 

Эм... а кто должен переключить задачу, чтобы это было аппаратное переключение в Вашем понимании? Монитор?

 

И в итоге все запутались

 

Узнается стиль микрософт: "попробуйте отгадайте по названию, что делает функция"
Eoi - это наверное сокращение от end of interrupt ?

 

barmaley57
Ну а что непонятного?
End-Of-Interrupt Helper for i386

 

Да все понятно! Просто название ни как не повествует о переключении потоков...

 

А Kei386EoiHelper и не переключает потоки.
Загляните в мою статью про процессы и потоки - узнаете и кто переключает и зачем, перепечатывать свой собственный текст мне откровенно впадлу.

 

barmaley57
Так трап-фрейм сказал ведь. Какимбы образом не была выполнена смена кольца защиты на нулевое(CPL), для каждого прерывания и пр. ядро формирует этот фрейм(это и есть контекст, полное состояние процессора) в текущем ядерном стеке, указатель на который сохраняется в описателе задачи - структуре ETHREAD. При возврате из прерывания этот контекст загружается в процессор. Именно это и делает та функция и название её как сказали верно. В принципе начало задачи очень расплывчато, условно можно разделить процесс загрузки новой задачи(формирование её) и начало её исполнения, формирует задачу планировщик, начиная с манипуляции структурами описывающими задачу, заканчивая переход в сегмент кода.

Аппаратная загрузка контекста из сегмента состояния задачи не может считаться програмной(хотя это относительно, на уровне например микрокода это програмный процесс..), так как им нельзя управлять или какимто образом контролировать, например процессор нельзя прервать когда он загрузит пол TSS, это делает одна инструкция, так что свич хардварный.

 

Читал сегодня второй раз (спасибо за труд!), но пока, честно говоря, в голове каша и соображать достаточно трудно. Прочитал приличное кол-во литературы и сейчас пытаюсь сложить все в общую картину. Да и с софтайсом знаком не так давно (больше в юзермоде сидел в Olly).
Тем не менее спасибо, что Вам не впадлу тратить свое время на ответы!

P.S. если не секрет, давно крутитесь в этом?

 

barmaley57
Он давно, ядро своё пишет(или написал уже..), так что вам до туда очень далеко.)

 

Главное не опускать руки

 

По-моему вы заблуждаетесь, товарищ!

 

Я так понимаю: программное (как-раз то, что делает винда) - это когда программист заботится о сохранении контекста прерываемой задачи.
Аппаратное - процессор сам сохраняет в TSS контекст задачи, загружает сегментные регистры и т.д. (то что происходит например при дальнем вызове шлюза задачи)
Поправьте если не так.

 

Так и не увидел описания Вашего понимания аппаратного переключения (задал вопрос об аппаратном, а в ответ опять "програмное"). В любом случае вот:
http://en.wikipedia.org/wiki/Task_switching#Software_vs_hardware_context_switching

 

barmaley57

Я с софтайсом, увы, тоже не особо знаком, поскольку он работал только на одном компе у меня 2 года назад, а сейчас на всех компах, что у меня есть, он либо зависает, либо бсодит
WinDbg всех порвёт!

Да что вы говорите!

 

Вы WinDbg используете в WinXP в режиме kernel debug? Или используете для удаленной отладки (живой или через VWWare например)?
Честно говоря, от интерфейса windbg немного офигеваешь (особенно после olly)
Может ткнете носом в какую-нибудь вменяемую литературу по WinDbg? Или help читать?
Спасибо.