Обнаружил глюк. Не пойму кто виноват?

Сёдня пол-дня искал причину почему глючит токошто написанный макрос.
Когда нашёл - офигел. Если после pusha, до первого обычного push будет любое изменение региста eax - исключение 0C0000005h (обращение по адресу не имея на то прав) . Любые команды после pusha выполняются нормально, а вот менять eax, пока не произведён хоть какой-нибудь push - нельзя!
Это Fasm глючит, или процессор? (проверить на других компиляторах нет возможности, а на совершенно разных процессорах Intel - одно и тоже ) Или это вообще не глюк, а так и должно быть?

 

gas
Так быть не должно. Полный минимальный пример, где проявляется описанная ситуация, в студию.

 

DEL (Практически дубль l_inc)

 

Скорее всего дело в этом. Смотрели в отладчике во что преобразуется Ваш код?

 

не может такого быть. Проверьте, не делаете ли вы обращение к [eax] вместо eax (то есть к памяти вместо регистра). В отладчике пошагово смотрели, что получается после макроса?

 

Отладчиком не пользуюсь (отлаживаю вставкой в исследуемые места макроса записывающего что надо в лог)

Глюк оказывается не везде, а только в макросах. Тот же самый код вставленный без макроса - работает.
Вот пример:
;-----------
macro ВЫВЕСТИ_S32 источник, место
{
pusha
pushf
xor eax,eax ;глюк вызывает любое изменение eax
pushd источник
mov ebx,место
pushd [ebx+_текст]
call SDword_в_строку
call Отрисовать
popf
popa
}
;-----------------
Если изменение eax вставить после pushd источник - работает
Если тот же код ставить без макроса (вместо "источник" и "место" прописать теми что передавалось в макрос) - работает

 

gas

Ахахах, как же вы тогда решили, что ошибка именно на инструкции xor eax, eax?

 

gas
Oh, come on! Опять Вы со своими русскими именами.

Минимальный полный пример нужен. На указанном коде никаких исключений не возникает.

 

Ezrah
В моём коде ошибка и явно на изменении eax (любом). И только если перед этим был pusha. После pushd xxxx с eax можно делать всё что угодно.

Ну, вобщем ясно - глючит Fasm... А я так был в нём уверен.

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

 

gas

Ну разумеется. Или на крайняк в винде баг. Или в процессоре. Но ни в коем случае не в коде. Вы ведь так круто его своими логами отладили.

В общем, как знаете.

 

l_inc
Зачем весь код? Достаточно того что я проверил - если xor eax,eax вставить в самом начале процедуры SDword_в_строку - что абсолютно ничего не меняет в принципе - глюка нет.

 

Напомнило мне это:
http://www.wasm.ru/forum/viewtopic.php?id=41711

 

gas
Затем, что я для чистоты эксперимента тоже проверил. Указанный макрос при раскрытии не вызывает никаких исключений.

 

Проявлю свои дедуктивные способности и умозаключу, что "место" передаётся в макрос через регистр eax.

 

Ezrah

Скорее это.

 

Ezrah
Да. Почти так и есть, только не место, а источник.

Что-то у меня подклинивает...

 

gas
Пользуйтесь отладчиком. http://ollydbg.de/odbg200.zip распакуйте, запускайте, перетаскивайте в него исполняемый файл, и всё.

 

gas
Даже в ассемблере место, где произошло исключение и его причина не обязательно по одному и тому же адресу происходят. На команде xor eax,eax исключение 0xC0000005 не может произойти.
Раз не хотите отладчик - поставьте команду загрузки не нуля. Например 0x400000
В конце концов включите полный листинг и посмотрите, что за команда стоит следом за xor eax,eax !
-----------------------------
А по принципу "чудес не бывает" : либо результат компиляции pushd содержит обращение к [EAX], либо что-то грузит в EAX , а оно потом у вас где-то используется!

 

gas, в общем код в студию. Так быстрее будет.

 

Igor1024
зачем тут код? Уже и так понятно, что при передаче в качестве источника eax, это

Код (Text):

1. xor eax,eax ;глюк вызывает любое изменение eax
2. pushd источник

разворачивается в

Код (Text):

1. xor eax, eax
2. push eax

и одна из следующих функций читает по нулевому указателю.