Была раньше тема про мониторы: Опасные мониторы.

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

Что надо сделать:

1. Открыть браузер на полный экран.
2. Открыть каждый тест в отдельной вкладке.
3. Пройтись и внимательно посмотреть, есть ли мерцание в каком-то (или в нескольких) из них.

Тесты:

• Тест 1: http://techmind.org/lcd/dotinv.html.
• Тест 2: http://techmind.org/lcd/dotinvrgb.html.
• Тест 3: http://techmind.org/lcd/dotinv2l.html.
• Тест 4: http://techmind.org/lcd/dotinv2lb.html.
• Тест 5: http://techmind.org/lcd/dotinvrgb2l.html.
• Тест 6: http://techmind.org/lcd/dotinvrgb2lb.html.

Наблюдал такое, что в полноэкранном режиме браузера мой монитор не мерцал ни в одном из тестов, а когда свернул браузер в пол-окна, то видел мерцание на 5-ом и 6-ом тестах, но в зависимости от положения окна браузера. Правда, как мне подсказали, это неправильный тест. Надо смотреть в полноэкранном режиме браузера!

В комментариях называйте именно номер теста, в котором видите мерцание.

Как пропатчить KDE2 под FreeBSD GOT-таблицу на MIPS?

Более практически меня интересует перехватить вызов функции xxx() скажем. При условии, что мой код стартует после загрузки всех .so и линковки. LD_PRELOAD — нельзя.

Т.е. на x86 понятно как. Я беру адрес xxx — он же является адресом внутри PLT, откуда я извлекаю адрес ячейки GOT, в которой записан реальный адрес функции, и подменяю его на свой.

Проблемы MIPS: во-первых нет PLT. В момент вызова функции генерируется код, который сразу лезет в GOT, извлекает адрес, кладёт в t9 и делает jalr t9. Из этого следствие, что непонятно как получить адрес ячейки GOT: если, на уровне ассемблера, я использую символ xxx, например, то команда la xxx мне сразу генерит код лезущий в GOT (оканчивающийся на lw t9, offs(gp)) — и в регистре сразу у меня адрес самой xxx. А мне нужно не значение символа xxx, а адрес ячейки GOT (не адрес функции xxx, а адрес адреса в GOT). И вот здесь я не понимаю — возможно ли, и если возможно то как записать такую конструкцию. Складывается впечатление, что невозможно. Но меж тем задача инжекции своей функции в чужой код она же можно сказать типовая. Должно же быть какое-то решение. Наконец, как-то же это делает линкер, на момент загрузки (хотя, он может читать ELF, а я не очень-то хочу).

Имеем ситуацию. Есть «тулкит» образца ~2006г. в составе имеет gcc-3.3.3, gdb-6.5, uclibc и binutils тех же времён... И включает он в себя ряд .so библиотек и программу. А моя задача дополнить это всё своей .so.

И имеем современное готовое ПО в исходниках, на C++, достаточно большого объёма и сложности, чтоб там не было желания что-то менять или отлаживать. Проблема в том, что похоже с gcc-3.3.3 оно не работает — ещё на этапе сборки натыкался на сбои в GCC, но обошёл, но после запуска тоже есть странности. Тем более, что взгляд на багтрекер для gcc-3.3.3 вызывает суицидальные настроения.

Вопрос. Можно ли взять более новую современную версию gcc и попросту пересобрать с теми же настройками (configure имеется ввиду) и начать использовать? Какие контраргументы?

Во-первых практический результат для gcc-4.8.4 (пересобрал gcc и binutils). Есть две программы: одна после этого даже не стартует. Валится в фиг знает где, gdb показывает полную чушь и попорченный стек. Вторая (маленькая, тест) стартует и даже как-то работает. Но gdb не показывает стек (bt) нормально, только пару-тройку функций сверху.

Во-вторых размышления на тему какие могут быть проблемы:

1) несовместимость ABI. Здесь (https://gcc.gnu.org/onlinedocs/libstdc /manual/abi.html) пунктом три приводятся версии libstdc++ для gcc и даны комментарии о несовместимости. В частности, для gcc-3.3.3 должно быть libstdc++.so.5 Практически у программы слинкованной gcc-4.8.4 есть зависимость тоже от libstdc++.so.5 (странно... хотя выше я пишу C++, но стандартная C++ библиотека вообще не используется — всё своё).

2) не знаю что ещё, надеюсь мне тут подскажут.

И, наконец, как быть. Использовать gcc-3.3.6 ? Кажется разумным вариантом. Но в имеющемся ПО дикий фарш из C++ кода и темплейтов, хоть формально всё и c++03, но судя по всему чем-то младше gcc-4.x никогда и не собиралось и не факт, что заработает. Хотелось бы потому gcc-4.x.

Платформа не x86, ежели что. Linux embedded, mips. Ядро и uclibc даны свыше (как и всё остальное), хидеров от ядра нет (uclibc пересобрать тоже сложно, но наверное можно, и вообще хотелось бы — но, насколько я понимая это вообще бессмысленно, ввиду несовместимости разных версий uclibc между собой).