Этот файл довольно хаотичен. Но после меток Geforce FX 6800 мы видим несколько идентификаторов. Скорее всего, нам нужен один из них. Давайте попробуем 00F1.
Проще всего протестировать это — воспользоваться LLDB и задать нужные точки останова. Я пропущу это этап, но скажу, что 00F1 подошёл (к счастью).
На этом этапе нам нужно ответить на вопрос: «Как сделать это изменение постоянным?» Похоже, что проще будет изменить значения var_CC и var_D0 на 0X00F1 и 0X10DE. Для этого нам всего лишь нужно получить пространство для кода.
Интересно, автор пробовал менять XMB файл вместо кода. По идее если 00F1 заменить на индификатор своей карты, то таким образом игра должна думать что у нас Geforce FX 6800… по идеи
Еще можно было бы #define return $#@!, чтобы вызвать синтаксическую ошибку — однако макросы не раскрываются рекурсивно, так что это не сработает и за пропущенным return, в отличии от endtry, приходится следить программисту.
Рекурсия не получится но можно использовать include
К примеру:
test.c:
#define TRY #include "inc.h"
int main(){
TRY
return 0;
}
Первой задачей стояла реализовать просто прокси, который будет всё принимать от клиента и пересылать на сервер и так же — в обратном направлении. Снова погрузиться в дебри асинхронщины.
А клиент с сервером общаются по Remote Protocol? Там вроде бы нет асинхронщины.
Пока client не получит ответ на команду, он следующую не посылает, если только это не Remote Non-Stop режим. Клиент всегда один.
Вроде бы Asio здесь будет чересчур.
Или есть нюансы?
Интересный опыт. Если есть возможность использовать готовый интерфейс SPI то конечно надо задействовать. А что использовали в качестве SPI? Что-то типа FTDI микросхему?
Видел еще интересный проект kuku.eu.org/?projects/stm8spi/stm8spi
Там задействовали SPI интерфейс Raspberry как отладочный SWIM интерфейс для микроконтроллеров STM8. Правда реализовали только загрузку прошивки.
И тут приходит мысль… А если в разрыв между GDB-client и GDB-server вставить посредника, осуществить, так сказать, MitM «атаку»? То есть, по сути, перехватить запросы, которые относятся к получению состояния потока, получить недостающую информацию от сервера и сформировать ответ клиенту?
Это все нужно что бы поддерживать threading для связки FreeRTOS и MicroBlaze?
Кто в этом случае будет GDB-client и GDB-server? Сервер вроде бы hw_server а вот кто клиент я так и не понял
Дилетантский вопрос. Если требовалось только прошить зачем нужно было разбираться с протоколом?
Ведь по идее можно снять дамп USB и просто гнать его в устройство, разве нет?
Если не выключить прерывания, программа всегда останавливается на первой инструкции любого из наступивших прерываний. А если их выключить, он больше не попадает в DebugMon_Handler
Выключать можно не все, а оставить только DebugMon_Handler, разве нет?
А давно NXP и Freescal стали Qualcomm? Можно какие-нибудь пруфы?
Интересно, автор пробовал менять XMB файл вместо кода. По идее если 00F1 заменить на индификатор своей карты, то таким образом игра должна думать что у нас Geforce FX 6800… по идеи
Уточните хотя бы почему=) NDA?
А вычисляемыми полями типа CRC он уже не справляется?
Вы под низкоуровневыми имеете ввиду smart deletion, smart addition
and smart splicing из статьи ?
Первое что подумал когда прочитал заголовок, зачем тут вообще Python, когда можно обойтись rm -rf ...
Дилетантский вопрос: почему задействовали такой специфический контроллер?
И еще интересует с каким отладчиком работает GDB-сервер hw_server ?
А есть какие-нить способы посмотреть преобразованный код? Без загрузки модуля
Например для отладки макроса
stackoverflow.com/a/30465750
Рекурсия не получится но можно использовать include
К примеру:
test.c:
inc.h:
gcc -E test.c:
А можно про это подробнее, не совсем понял что вы имели ввиду.
B gcc можно поставить хук на выход из ф-ции с момщью -finstrument-functions
и так ловить
А клиент с сервером общаются по Remote Protocol? Там вроде бы нет асинхронщины.
Пока client не получит ответ на команду, он следующую не посылает, если только это не Remote Non-Stop режим. Клиент всегда один.
Вроде бы Asio здесь будет чересчур.
Или есть нюансы?
Видел еще интересный проект kuku.eu.org/?projects/stm8spi/stm8spi
Там задействовали SPI интерфейс Raspberry как отладочный SWIM интерфейс для микроконтроллеров STM8. Правда реализовали только загрузку прошивки.
Это который идет в XSDK?
Получается что в нем нету поддержки потоков и xilinx предоставляет отладку только в режиме bare metal?
Это все нужно что бы поддерживать threading для связки FreeRTOS и MicroBlaze?
Кто в этом случае будет GDB-client и GDB-server? Сервер вроде бы hw_server а вот кто клиент я так и не понял
и чем это лучше чем просто
намного короче получается
К сожалению только частично ваш доклад смог послушать.
Ведь по идее можно снять дамп USB и просто гнать его в устройство, разве нет?
Про инструкцию перехода я как-то и забыл)
Выключать можно не все, а оставить только DebugMon_Handler, разве нет?