GCC, добавление кода в определенном месте делает программу нерабочей (изза размер кода видимо)?

Question

[spry]

Итак, имеем код для отладки того что происходит:

#define x86_emit_byte(value) \<br/>
 *translation_ptr = value; \<br/>
 translation_ptr++ \<br/>
<br/>
void function_cc x86_emit_translation_exit(p_u8 *p_translation_ptr)<br/>
{<br/>
 u8* translation_ptr = *p_translation_ptr;<br/>
 x86_emit_byte(0x90);<br/>
.... и так 100 строк...<br/>
 x86_emit_byte(0x90);<br/>
 *p_translation_ptr = translation_ptr;<br/>
}<br/>

Это кусок динамического транслятора, или же рекомпайлера. Изначально тут должен эмититься код размером около 100 байт, для теста представим что это все nop-ы. Так вот. Если емитить эти 100 байт вот так влоб, то транслятор перестает работать, не падает, просто перестает. По непонятным причинам. Если этот код заменить на цикл эмиттинга хоть килобайта nop-ов — все замечательно. Тоесть что зависит от размера самого транслятора а не кода что он эмитит. Обьектники транслятора относительно небольшие, до метра все 10 штук. Я уже 2 дня бьюсь над этим, но ничего пока не получается. Изначально транслятор не мой, я его редактирую, потому особо много рассказать не могу. Потому если что-то важное не уточнил, спрашивайте конечно. То что меня беспокоит — это одна функция которая вызывает этот кусок. Она размером в обьектнике около 0x70000 байт (о_О?). Уже не знаю на что грешить, поскольку транслятор не валится. Он просто перестает адекватно работать.

Comments

[spry]

Добавочная инфа:
после переноса этой функции в конец файла, оно начало работать нормально. Вернул обратно — перестало…

[spry]

Еще информация:
gba_u8* translation_ptr = *p_translation_ptr;
int i;
for(i=0;i<1000; i++)
{
// если первая строчка, работает
//x86_emit_byte(0x90);
// а вот если вторая, то не работает
asm("nop");
}

x86_emit_byte(0x90);
x86_emit_byte(0x90);
.....
x86_emit_byte(0x90);


Я удивляюсь, громко так

[spry]

Удалось более менее «локализировать» баг
void function_cc x86_emit_translation_exit(p_gba_u8 *p_translation_ptr)
{
gba_u8* translation_ptr = *p_translation_ptr;
int i;
// 904 works
// 903 does not
for(i=0;i<904; i++)
{
x86_emit_byte(0x90);
}

*p_translation_ptr = translation_ptr;
}


Все интересней и интересней. Тоесть это не глюк при компиляции из-за размера. А из-за того, что емитит эта функция. Жаль я изначально не проверил это, а сразу проверял на большиш числах (1000 емитов нопа). И вот что странное — если много емитить (904) то все работает. А если мало (903 и меньше) — не работает. Если бы было наоборот я бы грешил на то что я гдето вылажу за границы неизвветсного емита джампа (поскольку транслятор еще и из емитированого кода вызывается). У меня идеи закончились

[spry]

при значении 10 не работает, при значении 200 снова работает. Что это может быть?

[spry]

// 0-7 works
// 8 does not
// 12 does not
// 15 does not
// 16 does not
// 20 does not
// 100 does not
// 125 does not
// 135 does not
// 136 does work
// 150 does work
// 200 does work
// (244) 8+128+108 does work
// (263) 8+128+127 does work
// (264) 8+128+128 does not
// (363) 8+128+128+100 does not
// (391) 8+128+128+127 does not
// (392) 8+128+128+128 does work
// (492) 8+128+128+128+100 does work

Немного потестил еще, и вот что получил.
0-7 байт нопов = работает
8-135 байт нопов = не работает.
И так далее с шагом 127/128 байт работает/не работает. Мне кажется чтото связанное или с чем-то непонятным, или с short jump… так?

[spry]

Три раза проверил, в емиттере используются только near jcc (0x0F 0x8?) + dword и near jmp (0xE9) + dword. Теперь я уже не могу понять откуда берется зависимость в 127/128 байт

Answer 1

[mt_]

А если записать дефайн в одну строчку, заработает?
#define x86_emit_byte(value) *(translation_ptr++) = value;

Comments

[spry]

Нет, попробовал, не помогло

Answer 2

[mraleph]

Информации, конечно, маловато для осмысленного совета, но вот что бы я сделал:

0) для очистки совести и исключения бага gcc отключил бы оптимизации -O0, скорее всего проблема как была так и останется, и можно будет проглядеть неоптимизированный код этой функции и убедится, что гцц ничего не наврал;

1) вместо восьми nop (малейшее значение при котором перестает работать), выдал бы 7 nop и 1 int 3 (0xCC). или много-много int 3 и посмотрел кто на них наступает, на эти «нопы» и что там за ними следует, куда там потом управление после этих нопов должно попасть (может там мусор какой-то?)

Comments

[spry]

1) "-O0 -g3" уже :)
2) Изначально этот емиттер при определенных обстоятельствах в одном месте (при генерации прыжка на бранч)
call branched_update_notify
jmp (адрес_бранча)

Мне нужно врезатся как раз после вызова нотификации апдейта (это С-функция, которая смотрит не прошел ли V-sync уже) и до прыжка в новый бранч выполнения. Недолго думая, я вставил вызов своей функции емита нопов между емитами call и jmp. Я думаю может стоит вместо нопов заэмитить код примерно такого вида
jmp original_jump_after_my_code
int 3 # такое количество раз чтобы оно не работало

Я так думаю что если туда вместо нопов втулить код который будет чтото важное делать (даже «рабочего» размера) все свалится, потому как мне кажется чтото прыгает в нетуда, но попадая на нопы не валится. Что-то мне подсказывает что так и есть, пойду тестить!

[mraleph]

если вы врезаетесь в сгенерированный/генерируемый рекомендую убедится, что все относительные call/jmp (пере)вычисляются корректно.

[spry]

Генерируемый. Да, существует вероятность что я где-то что-то не обновляю, вот бы еще понять где если это так. Протестировал как говорил — первый мной эмит это 5 байт относильного джампа на то место которое оригинально после моего кода (чтобы не мешать работе программы а проверить не попадает ли чтото в сгенерированый уже мною код на прямую), все место между моим и не моим джампом (в данном случае 100 байт — которые не работают точно) заполнил 0хСС, оно по прежнему не работает, но и не вылетает с sigtrap. Тоесть в в 100 байт из 105 точно никто на прямую не прыгает. Я уж было надеялся хоть что-то новое увидеть :)

[spry]

И кажет ся я увидел то что искал, через пару минут отпишусь!

[spry]

Вывод ассемблера (синтаксис AT&T) после использования описанного выше теста:
0xb695a018 int3 # мой первый sigtrap для попадания сюда вообще
0xb695a019 jns 0xb695a029 # какая-то оригинальная проверка, прыгает на "после-апдейта"
0xb695a01f mov $0x80000c0,%eax
0xb695a024 call 0x8126eab <update_x86>
0xb695a029 jmp 0xb695a036 # это уже код который я эмитил, прыжок на "после-моего-кода"
0xb695a02e int3 # много много 0хСС для проверки не попадает ли сюда кто-то случайно, а с помощью джампа до этого
0xb695a02f int3 # просто так валидно сюда не попадеш
0xb695a030 int3
0xb695a031 int3
0xb695a032 int3
0xb695a033 int3
0xb695a034 int3
0xb695a035 int3
0xb695a036 jmp 0xb695a043 # снова оригинальный джамп, тот который изначально был "после-апдейта"
0xb695a03b rolb $0x0,(%eax) # обратите внимание на адрес в джампе строчкой выше (0xb695a043)
0xb695a03e or %al,(%eax)
0xb695a040 add %al,(%eax)
0xb695a042 add %bh,0x12(%eax)
0xb695a048 call 0x81b21a7 <execute_mov> # джамп который меня заинтересовал, оригинальный должен прыгнуть сюда
0xb695a04d mov %eax,(%ebx)

Странность, адрес в джампе (помним, он оригинальный) 0xb695a043, а инструкции именно по этому адресу нету. Ну или может быть между джампом и адресом куда прыгаем мусор, который конфузит дизасмер еклипса. Пойду посмотрю в gdb

[spry]

Да, между последним джампом оригинальным и тем местом куда он прыгает мусор, дизасм места прыжка
0xb695a043 mov $0x12,%eax │
│0xb695a048 call 0x81b21a7 <execute_mov> │
│0xb695a04d mov %eax,(%ebx) │
│0xb695a04f mov (%ebx),%eax │
│0xb695a051 mov $0xff0000ff,%edx │
│0xb695a056 call 0x8127270 <execute_store_cpsr>

Так что прыжок куда нужно, и даже правильно. 95% это не то место где что-то поехало, но тем не менее я не могу представить почему оно не работает

[mraleph]

заметим мистическую связь: 0xb695a036-0xb695a029 == 13, 0xb695a043 — 0xb695a036 == 13. у меня такое ощущение, что где-то при вычислении относительного смещения для второго прыжка используется какой-то неправильный/необновленный указатель.

[spry]

И еще одно интересное. В немодифицированом коде расстояние между последним джампом и валидным местом куда оно прыгает — 8 байт.

[spry]

и значения в этих 9 байтах 0xC0 0x00 0x00 0x00 0x08 0x00 0x00 0x00

[spry]

8 байтах

Answer 3

[Trotil]

А указатель, передаваемый в функцию, на что именно указывает?
Он может занопить кусок какого-то кода, причём после затирание фрагмента определённой величины может не привести к плохим последствиям, а вот больше или меньше — уже вызовет проблему.

Comments

[spry]

Нет, память дальше пустая, еще не записаная. Появилась другая зависимость, сейчас опишу выше.

[spry]

Посмотрите выше, я добавил информации. Так как это проявляется с периодичностью, то скорее всего это связанно с прыжком в нетуда. Или я что-то упустил?

Answer 4

[Trotil]

Посмотрел.
Короче, вы записываете ассемблерные вставки по какому-то диапазону адресов *p_translation_ptr = 0x90, а затем зачем-то пихаете туда сам адрес последней инструкцией:

*p_translation_ptr = translation_ptr;

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

Извините, что если не так понял в коде — спать хочется.

Comments

[Trotil]

Тьфу, точно спать пора — не увидел разницы между p_translation_ptr и translation_ptr.