Question

I am trying to use the MinGW GCC toolchain on XP with some vendor code from an embedded project that accesses high memory (>0xFFFF0000) which is, I believe, beyond the virtual mem address space allowed in civilian processes in XP.

I want to handle the memory access exceptions myself in some way that will permit execution to continue at the instruction following the exception, ie ignore it. Is there some way to do it with MinGW? Or with MS toolchain?

The vastly simplified picture is thus:

/////////////
// 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
}

More detail: I am developing an embedded project on an Atmel AVR32 platform with freeRTOS using the AVR32-gcc toolchain. It is desirable to develop/debug high level application code independent of the hardware (and the slow avr32 simulator). Various gcc, makefile and macro tricks permit me to build my Avr32/freeRTOS project in the MinGW/Win32 freeRTOS port enviroment and I can debug in eclipse/gdb. But the high-mem HW access in the (vendor supplied) Avr32 code crashes the MinGW exe (due to the mem access exception).

I am contemplating some combination of these approaches:

1) Manage the access exceptions in SW. Ideally I d be creating a kind of HW simulator but that d be difficult and involve some gnarly assembly code, I think. Alot of the exceptions can likely just be ignored.

2) Creating a modified copy of the Avr32 header files so as to relocate the HW register #defines into user process address space (and create some structs and linker sections that commmit those areas of virtual memory space)

3) Conditional compilation of function calls that result in highMem/HW access, or alernatively more macro tricks, so as to minimize code cruft in the real HW target code. (There are other developers on this project.)

Any suggestions or helpful links would be appreciated.

This page is on the right track, but seems overly complicated, and is C++ which I d like to avoid. But I may try it yet, absent other suggestions. http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh

Answer 1

You need to figure out why the vendor code wants to write 1 to address 0xFFFF0000 in the first place, and then write a custom VendorFunc_B() function that emulates this behavior. It is likely that 0xFFFF0000 is a hardware register that will do something special when written to (eg. change baud rate on a serial port or power up the laser or ...). When you know what will happen when you write to this register on the target hardware, you can rewrite the vendor code to do something appropriate in the windows code (eg. write the string "Starting laser" to a log file). It is safe to assume that writing 1 to address 0xFFFF0000 on Windows XP will not be the right thing to do, and the Windows XP memory protection system detects this and terminates your program.

Answer 2

I had a similar issue recently, and this is the solution i settled on:

Trap memory accesses inside a standard executable built with MinGW

First of all, you need to find a way to remap those address ranges (maybe some undef/define combos) to some usable memory. If you can t do this, maybe you can hook through a seg-fault and handle the write yourself.

I also use this to "simulate" some specific HW behavior inside a single executable, for some already written code. However, in my case, i found a way to redefine early all the register access macros.

友情链接