Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
[NT] Просто интересно... 15.07.03 18:23 Число просмотров: 1596
Автор: amirul <Serge> Статус: The Elderman
|
> А вот у меня такой странный вопрос назрел: почему XP при
> вызове сервисов ядра из пользовательского режима исполняет
> SYSENTER, а NT4 исполняет INT 2E. В чём отличия, или просто
> мода пошла такая? ;-)))
> Subj.
>
> Заранее всем спасибо за ответы.
цЫтата с МСДН-а:
Fast System Calls
One other performance improvement is in the area of system call dispatching. Those familiar with the internals of Windows NT associate the assembly language instruction "INT 0x2E" with system calls, since it's with this instruction that Windows NT and Windows 2000 transition from user mode to the kernel-mode system call interface where the native API is implemented. Many Win32 APIs invoke system calls. Windows XP uses the SYSENTER/SYSEXIT pair of instructions to transition into and out of kernel-mode for system calls if it's running on a Pentium II or higher. This instruction sequence requires fewer clock cycles to execute, improving the speed of system calls.
http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/default.aspx
|
|
<operating systems>
|
[NT] Просто интересно... 15.07.03 17:44
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 15.07.03 17:46 Количество правок: 1
|
А вот у меня такой странный вопрос назрел: почему XP при вызове сервисов ядра из пользовательского режима исполняет SYSENTER, а NT4 исполняет INT 2E. В чём отличия, или просто мода пошла такая? ;-)))
Subj.
Заранее всем спасибо за ответы.
|
|
[NT] Просто интересно... 15.07.03 18:23
Автор: amirul <Serge> Статус: The Elderman
|
> А вот у меня такой странный вопрос назрел: почему XP при
> вызове сервисов ядра из пользовательского режима исполняет
> SYSENTER, а NT4 исполняет INT 2E. В чём отличия, или просто
> мода пошла такая? ;-)))
> Subj.
>
> Заранее всем спасибо за ответы.
цЫтата с МСДН-а:
Fast System Calls
One other performance improvement is in the area of system call dispatching. Those familiar with the internals of Windows NT associate the assembly language instruction "INT 0x2E" with system calls, since it's with this instruction that Windows NT and Windows 2000 transition from user mode to the kernel-mode system call interface where the native API is implemented. Many Win32 APIs invoke system calls. Windows XP uses the SYSENTER/SYSEXIT pair of instructions to transition into and out of kernel-mode for system calls if it's running on a Pentium II or higher. This instruction sequence requires fewer clock cycles to execute, improving the speed of system calls.
http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/default.aspx
|
| |
Понятно, спасибо. Тогда следующее... 16.07.03 07:09
Автор: HandleX <Александр М.> Статус: The Elderman
|
Борландовский встроенный дебуггер вызывает исключение в отлаживаемом приложении, когда пошагово трассируешь прогу до SYSENTER.
Никто не знает, почему?
|
| | |
Не знаю точно. Мои предположения 16.07.03 09:33
Автор: amirul <Serge> Статус: The Elderman
|
> Борландовский встроенный дебуггер вызывает исключение в
> отлаживаемом приложении, когда пошагово трассируешь прогу
> до SYSENTER.
>
> Никто не знает, почему?
Понятное дело, что для смены режима с юзера на ядро нужно или call-gate или trap или int ну короче какое-нить прерывание-исключение. Обычно дебаггеры ставят хендлеры на все исключения о которых не знают, что они системные, так что старый дебаггер может отлавливать попытку перехода винды в ядро, потому как не уверен, что юзерские процессы могут делать новый вид перехода.
Из методов лечения могу предложить попробовать сменить версию на более актуальную (хотя на самом деле руки чешутся предложить сменить компилятор :-))) )
|
| | | |
Не знаю точно. Мои предположения 16.07.03 13:35
Автор: HandleX <Александр М.> Статус: The Elderman
|
> Понятное дело, что для смены режима с юзера на ядро нужно
> или call-gate или trap или int ну короче какое-нить
> прерывание-исключение. Обычно дебаггеры ставят хендлеры на
> все исключения о которых не знают, что они системные, так
> что старый дебаггер может отлавливать попытку перехода
> винды в ядро, потому как не уверен, что юзерские процессы
> могут делать новый вид перехода.
Просто дело вот в чём. Вызываешь, к примеру, Beep(). Трассируешь это дело... В конце концов доходишь до NTDeviceIOControlFile(), там трассируется нормально, трассируется и SYSENTER (дебуггер кстати правильно пишет эту инструкцию, т.е. он с ней знаком), компутер пищит (т.е. всё нормально, поскольку Beep ж-), и управление дебуггер получает на строке после SYSENTER, и дальше всё нормально, но через десяток-другой инструкций наступает AccessViolation по памяти. А если недоходя до SYSENTER где-то после него установить breakpoint и сделать run, то всё нормально.
> Из методов лечения могу предложить попробовать сменить
> версию на более актуальную (хотя на самом деле руки чешутся
> предложить сменить компилятор :-))) )
Да некуда актуальней, самое свежее вареzz... А васиковский отладчик также себя ведёт?
|
| | | | |
Васик - это VB? 16.07.03 14:27
Автор: amirul <Serge> Статус: The Elderman
|
Если да - то не знаю и знать не хочу :-)
> Просто дело вот в чём. Вызываешь, к примеру, Beep().
> Трассируешь это дело... В конце концов доходишь до
> NTDeviceIOControlFile(), там трассируется нормально,
> трассируется и SYSENTER (дебуггер кстати правильно пишет
> эту инструкцию, т.е. он с ней знаком), компутер пищит (т.е.
> всё нормально, поскольку Beep ж-), и управление дебуггер
> получает на строке после SYSENTER, и дальше всё нормально,
> но через десяток-другой инструкций наступает
> AccessViolation по памяти. А если недоходя до SYSENTER
> где-то после него установить breakpoint и сделать run, то
> всё нормально.
> Да некуда актуальней, самое свежее вареzz... А васиковский
> отладчик также себя ведёт?
В VC попробовал в 6-м. SYSENTER тоже показывается, но вот при попытке step into - beep и access violation. Нельзя все таки под дебаггером вызывать exception-ы. Вот я себе и представляю: любой человек, который в состоянии отлаживать свои процессы запросто заходит в 0-е кольцо и продолжает отладку там, попутно меняя регистры и память.
Короче, мое мнение SYSENTER выполняет свои функции, но попутно почему-то запускает SEH.
Для таких вещей softice нужен имхо.
|
| | | | | |
Нет, я ошибся немного и имел ввиду M$ VC. 16.07.03 14:40
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 16.07.03 14:45 Количество правок: 2
|
> В VC попробовал в 6-м. SYSENTER тоже показывается, но вот
> при попытке step into - beep и access violation. Нельзя все
> таки под дебаггером вызывать exception-ы. Вот я себе и
> представляю: любой человек, который в состоянии отлаживать
> свои процессы запросто заходит в 0-е кольцо и продолжает
> отладку там, попутно меняя регистры и память.
>
> Короче, мое мнение SYSENTER выполняет свои функции, но
> попутно почему-то запускает SEH.
>
> Для таких вещей softice нужен имхо.
Понятно. Оказывается, борландовский дебугер круче M$, у него не сразу AccessViolation возникает ;-)
Я думаю, что-то там со сменой контекста после SYSENTER и/или с тем, что, по сути, дебуггер при трассировке подменяет ту инструкцию, на которой он должен остановится, на INT 3. А потом что-то там у него косяк какой-то происходит.
В принципе, понятно, что отладчик пользовательского режима не должен и не сможет влезть в ноль.
В общем, сплошная загадка.
А что такое SEH?
И ещё вопрос. Вот, процессор поддерживает т.н. Debug Extencions. С чем их едят и могут ли использовать это дело отладчики пользовательского режима?
|
| | | | | | |
Нет, я ошибся немного и имел ввиду M$ VC. 16.07.03 15:51
Автор: amirul <Serge> Статус: The Elderman
|
> Понятно. Оказывается, борландовский дебугер круче M$, у
> него не сразу AccessViolation возникает ;-)
:-))) Ну это тоже спорный вопрос. Вообще-то ошибка должна индицироваться как можно ближе к тому месту, где возникла
> Я думаю, что-то там со сменой контекста после SYSENTER
> и/или с тем, что, по сути, дебуггер при трассировке
> подменяет ту инструкцию, на которой он должен остановится,
> на INT 3. А потом что-то там у него косяк какой-то
> происходит.
> В принципе, понятно, что отладчик пользовательского режима
> не должен и не сможет влезть в ноль.
> В общем, сплошная загадка.
>
> А что такое SEH?
Ну Structured Exception Handling - виндовый механизм управления исключениями. В общем любое неправильное исключение процессора в конце концов генерит SEH-исключение.
> И ещё вопрос. Вот, процессор поддерживает т.н. Debug
> Extencions. С чем их едят и могут ли использовать это дело
> отладчики пользовательского режима?
Extensions? Вроде это стандартно в IA32. Может Debug Exceptions? Если да, то exception по содержимому Debug Register-а. Те которые в SoftICE ставятся с помощью bpm. В этом случае память вообще не меняется. Но процессор вылетает в debug exception (#DB - vector 1)
Если интересно скачай http://developer.intel.ru/design/pentium4/manuals/245472.htm - незаменимо при low level (даже ниже ОСи) программировании под IA32
И попутно довольно полезно будет скачать и первые два тома.
http://developer.intel.ru/design/pentium4/manuals/245472.htm
|
| | | | | | | |
SiSoft Sandra — CPU & BIOS Information — Debugging Extension — Yes. 16.07.03 16:03
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
