Всем злого времени суток - доброго желать надоело. Читал тут на днях мануалы от Интела и заинтересовался разделом по EFLAGS, в частности, есть там такой бит под номером 16 (bit 16) Resume. Так вот талмуды гласят, что будучи установленным, он временно отключает генерацию иксепшенов типа #DB, т.е., как я понял, лепка опкодов CC больше не даст бряков. Я через pushfd считал его значение, в нём через or взвёл этот чудесный бит, и через popfd затолкал всё с изменениями в этот регистр. Но ничего не поменялось - иксепшены как были, так и остались, а бит в этом регистре снова сбросился назад. Почему?

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

советую еще раз почитать мануалы
на крайний случай - у КК и Клерка была некоторая информация об этом.

| Сообщение посчитали полезным:

n0name
Почитал ещё раз. Ну, написано, что отладочный софт должен править образ EFLAGS непосредственно перед возвратом в прерванную прогу перед IRETD, причём править значение в стэке. Но должен - растяжимое понятие, там же не написано, почему не работает так, как я делаю. И вообще, развёрнутые ответы со ссылками приветствуются.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

Ну прокури ман ещё 3 раза, что я могу сказать. Во-первых, popfd его не меняет, а только iretd. Во-вторых, он сбрасывается автоматически после первой же выполненной инструкции. В-третьих, он отключит дебаг-регистры. Вроде, нигде не ошибся, ибо разбирался давно и писал по памяти.

| Сообщение посчитали полезным:

Archer
Теперь ясно. Правда, не ясно, что бы мне дало ещё трёхразовое чтение. ИМХО, трёхразовое чтение, в отличие от трёхразового питания, пользы не приносит. Короче, на антидебаг этот бит не тянет. Тему пока не закрываю - может, кто-то ещё захочет высказаться.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

PUSHFD, POFD не изменяют флаг RF, взводится после(!) команды IRETD на некоторое время, чтобы та же самая команда не вызвала исключение #DB. А для инструкции INT 3 с кодом 0xCC есть исключение #BP. Его вызов этот флаг не отключает. Вот Debug-регистры не отключит.

Кроме всего этого есть еще какой-то случай, когда этот флаг устанавливается. У меня вот такие дела
#UD
{#GP(0)} много раз до переполнения стека, и всегда этот флаг взведен

-----
IZ.RU

| Сообщение посчитали полезным:

ARCHANGEL
18.3.1.1
> Note that the POPF, POPFD, and IRET instructions do not transfer
the RF image into the EFLAGS register.
Юзайте прерывания для этих целей. Например последовательность Int 0x2A не будет генерировать трассировачный останов.
Кстате 0xCC генерит #BP, а не #DB - оно и понятно, камень инструкцию пропустить не может.

| Сообщение посчитали полезным:

Это вы какой мануал читаете? Не --> IA-32 Intel Architecture <-- часом? Если нет, то дайте и мне ссылочку тоже, плиз.

-----
IZ.RU

| Сообщение посчитали полезным:

5 копеек. RF лочит только брекопойнты по команде, всем остальным пофигу

| Сообщение посчитали полезным:

Дополняю и исправляю свои слова.

Исследования креш-дампов наводят на мысль, что вообще при любых исключениях, или, может быть, почти при любых, RF взводится, чтобы запретить #DB, которое "...вызывается (1)как ловушка при пошаговой трассировке (флаг TF = 1), (2)при переключении на задачу с установленным TF и (3)при срабатывании точки останова во время доступа к данным, определенной в отладочных регистрах. " Archer прав на все 100.

-----
IZ.RU

| Сообщение посчитали полезным:

RF подавляет только #DB на адрес инструкции, больше никак. Хотя можно было бы ожидать, что она могла бы подавлять и #DB при dr7.gd=1 и следующей инструкции, пишущей/читающей отл.регистры. Однако это не так, в этом случае почему то и mov ss,... не подавляет, детект чтения записи отл.регистров подчиняется другой логике

| Сообщение посчитали полезным:

DenCoder пишет:
Исследования креш-дампов наводят на мысль, что вообще при любых исключениях, или, может быть, почти при любых, RF взводится, чтобы запретить #DB, которое "...вызывается (1)как ловушка при пошаговой трассировке (флаг TF = 1), (2)при переключении на задачу с установленным TF и (3)при срабатывании точки останова во время доступа к данным, определенной в отладочных регистрах. " Archer прав на все 100. ,
Наоборот, RF сбрасывается во всех случаях, в т.ч . и при sysenter.
ЗЫ
Про задачу с установленным TSS.T - порадовал, в каком софте ты это видел!? Всегда считал, что это ненужная/неиспользуемая фишка интела

| Сообщение посчитали полезным:

spinz, Зубков так пишет. Проверить это на практике стоит некоторых трудов. По-моему это полезно... для отладчиков на другой оси...
Зубков ничего не писал, что RF сбрасывается или устанавливается при возникновении некоторых исключений. Опровержения или подтверждения этому пока не нашел. С другой стороны, как объяснить то, что у меня в стеке всегда RF взведен от начала возникновения #UD?

ЗЫ. Вот бы мне помог в моем дневнике...

-----
IZ.RU

| Сообщение посчитали полезным:

га, извини, подтупил, RF наоборот при большинстве исключений в стеке устанавливается в 1, спасибо, не знал. Правда я хоть убей не пойму почему при #DB в стеке EFLAGS.RF=0, при остальных (за исключением внешних интераптов) = 1

| Сообщение посчитали полезным:

Всё, всем спасибо - тема закрыта.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным: