Обработка исключений при доступе к памяти с MinGW на XP - PullRequest
Новая
       17

Обработка исключений при доступе к памяти с MinGW на XP

0 голосов
/ 04 мая 2011

Я пытаюсь использовать набор инструментов MinGW GCC в XP с кодом какого-либо поставщика из встроенного проекта, который обращается к высокому объему памяти (> 0xFFFF0000), который, как мне кажется, выходит за рамки виртуального адресного пространства, разрешенного в «гражданских» процессах в XP .

Я хочу обработать исключения доступа к памяти каким-либо образом, что позволит продолжить выполнение инструкции, следующей за исключением, т.е. игнорировать его. Есть ли способ сделать это с MinGW? Или с помощью MS Toolchain?

Значительно упрощенная картина выглядит так: 

/////////////
// MyFile.c
MyFunc(){
    VendorFunc_A();
}

/////////////////
// VendorFile.c
VendorFunc_A(){
    VendorFunc_DoSomeDesirableSideEffect();
    VendorFunc_B();
    VendorFunc_DoSomeMoreGoodStuff();
}

VendorFunc_B(){
    int *pHW_Reg = 0xFFFF0000;
    *pHW_Reg = 1;  // Mem Access EXCEPTION HERE
    return(0);     // I want to continue here
}

Подробнее: Я занимаюсь разработкой встроенного проекта на платформе Atmel AVR32 с freeRTOS, используя набор инструментов AVR32-gcc. Желательно разрабатывать / отлаживать код приложения высокого уровня независимо от аппаратного обеспечения (и медленного симулятора avr32). Различные трюки gcc, makefile и макросов позволяют мне создавать мой проект Avr32 / freeRTOS в среде портов FreeRTOS MinGW / Win32, и я могу отлаживать в eclipse / gdb. Но HW-доступ с высоким мемом в коде Avr32 (поставляется поставщиком) приводит к сбою exe-файла MinGW (из-за исключения доступа к mem).

Я рассматриваю некоторую комбинацию этих подходов:

1) Управление исключениями доступа в ПО. В идеале я хотел бы создать своего рода симулятор HW, но это было бы сложно и, я думаю, потребовало бы некоторого грубого ассемблерного кода. Многие исключения могут быть просто проигнорированы.

2) Создание модифицированной копии заголовочных файлов Avr32 для перемещения регистра HW #defines в адресное пространство пользовательского процесса (и создания некоторых структур и секций компоновщика, которые передают эти области виртуальной памяти)

3) Условная компиляция вызовов функций, которые приводят к доступу highMem / HW, или к большему количеству макро-трюков, чтобы минимизировать смещение кода в «реальном» коде HW-цели. (В этом проекте есть другие разработчики.)

Будем благодарны за любые предложения или полезные ссылки.

Эта страница находится на правильном пути, но кажется слишком сложной и представляет собой C ++, которого я хотел бы избежать. Но я могу попробовать это, без других предложений. http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh

Ответы [ 2 ]

1 голос
/ 07 августа 2011

Вам необходимо выяснить, почему код поставщика хочет сначала написать 1 по адресу 0xFFFF0000, а затем написать собственную функцию VendorFunc_B (), которая эмулирует это поведение.Скорее всего, 0xFFFF0000 - это аппаратный регистр, который при записи будет делать что-то особенное (например, изменять скорость передачи данных в последовательном порту или включать лазер или ...).Когда вы знаете, что произойдет при записи в этот регистр на целевом оборудовании, вы можете переписать код поставщика, чтобы сделать что-то подходящее в коде Windows (например, записать строку «Запуск лазера» в файл журнала).Можно с уверенностью предположить, что запись 1 по адресу 0xFFFF0000 в Windows XP не будет правильным решением, и система защиты памяти Windows XP обнаружит это и завершит работу вашей программы.

0 голосов
/ 28 февраля 2019

У меня недавно была похожая проблема, и на этом я остановился:

Доступ к памяти ловушек внутри стандартного исполняемого файла, созданного с помощью MinGW

Прежде всего, вам нужно найти способ переназначить эти диапазоны адресов (возможно, несколько комбинаций undef / define) в некоторую полезную память. Если вы не можете сделать это, возможно, вы можете перехватить ошибку сегмента и обработать запись самостоятельно.

Я также использую это, чтобы "имитировать" некоторое специфическое поведение HW внутри одного исполняемого файла для некоторого уже написанного кода. Однако в моем случае я нашел способ переопределить все макросы доступа к реестру на ранней стадии.

...