XP 上使用 MinGW 处理内存访问异常
我正在尝试在 XP 上使用 MinGW GCC 工具链以及来自嵌入式项目的一些供应商代码，该项目访问高内存（> 0xFFFF0000），我相信这超出了 XP 中“民用”进程允许的虚拟内存地址空间。
我想以某种方式自己处理内存访问异常，从而允许在异常之后的指令处继续执行，即忽略它。有什么办法可以用 MinGW 来实现吗？或者使用 MS 工具链？
因此，大大简化的图片是：
/////////////
// 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
}
更多细节： 我正在使用 AVR32-gcc 工具链在带有 freeRTOS 的 Atmel AVR32 平台上开发一个嵌入式项目。开发/调试独立于硬件（和慢速 avr32 模拟器）的高级应用程序代码是可取的。各种 gcc、makefile 和宏技巧允许我在 MinGW/Win32 freeRTOS 端口环境中构建我的 Avr32/freeRTOS 项目，并且我可以在 eclipse/gdb 中进行调试。但是（供应商提供的）Avr32 代码中的高内存硬件访问会使 MinGW exe 崩溃（由于内存访问异常）。
我正在考虑这些方法的某种组合：
1）管理软件中的访问异常。理想情况下，我会创建一种硬件模拟器，但这会很困难，并且涉及一些粗糙的汇编代码，我认为。许多例外情况可能会被忽略。
2) 创建 Avr32 头文件的修改副本，以便将硬件寄存器 #defines 重新定位到用户进程地址空间（并创建一些提交这些虚拟内存空间区域的结构体和链接器部分）
3) 条件编译函数调用导致 highMem/HW 访问，或者更多的宏技巧，以便最大限度地减少“真实”硬件目标代码中的代码冗余。 （这个项目还有其他开发人员。）
任何建议或有用的链接将不胜感激。
这个页面是在正确的轨道上，但似乎过于复杂，并且是我想避免的 C++。但如果没有其他建议，我可能会尝试一下。 http://www.programmingunlimited.net/siteexec/content.cgi?page =mingw-seh
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您首先需要弄清楚为什么供应商代码要向地址 0xFFFF0000 写入 1，然后编写一个模拟此行为的自定义 VendorFunc_B() 函数。 0xFFFF0000 很可能是一个硬件寄存器，在写入时会执行一些特殊操作（例如，更改串行端口上的波特率或启动激光器或...）。当您知道在目标硬件上写入该寄存器时会发生什么时，您可以重写供应商代码以在 Windows 代码中执行适当的操作（例如，将字符串“Starting Laser”写入日志文件）。可以肯定地认为，在 Windows XP 上向地址 0xFFFF0000 写入 1 不是正确的做法，Windows XP 内存保护系统会检测到这一点并终止您的程序。
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.
我最近遇到了类似的问题，这是我确定的解决方案：
将内存访问捕获到使用 MinGW 构建的标准可执行文件中
首先，您需要找到一种方法将这些地址范围（可能是一些 undef/define 组合）重新映射到一些可用内存。如果你做不到这一点，也许你可以通过一个段错误来挂钩并自己处理写入。
对于一些已经编写的代码，我还使用它来“模拟”单个可执行文件内的某些特定硬件行为。然而，就我而言，我找到了一种方法来尽早重新定义所有寄存器访问宏。
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.