LINUX.ORG.RU

Избранные сообщения fk0

А ваш монитор прошел тест на безопасность?

Голосования — Голосования

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

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

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

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

Тесты:

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

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

  1. Ничего не мерцает476 (62%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Тест 5: мерцание!160 (21%)

    ***********************************************************************************************************

  3. Тест 6: мерцание!142 (19%)

    ***********************************************************************************************

  4. Тест 4: мерцание!95 (12%)

    ***************************************************************

  5. Тест 3: мерцание!92 (12%)

    *************************************************************

  6. Тест 2: мерцание!66 (9%)

    ********************************************

  7. Тест 1: мерцание!50 (7%)

    *********************************

Всего голосов: 1081, всего проголосовавших: 766

>>> Результаты

 , , , ,

Maniac_with_a_saw ()

Пропатчить GOT таблицу на MIPS.

Форум — Development

Как пропатчить 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, а я не очень-то хочу).

 , ,

fk0 ()

Использование GCC разных версий при сборке библиотек, C++.

Форум — Development

Имеем ситуацию. Есть «тулкит» образца ~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 между собой).

 , , , ,

fk0 ()