需要一些MinGW PE支持 [英] Need some MinGW PE-support support

查看:120
本文介绍了需要一些MinGW PE支持的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用CodeBlocks(12.11 rev 8629,SDK 1.13.14)构建一个32位Windows可执行文件,ArchQORDemo.exe



命令行是如下: -



mingw32-g ++。exe -std = c ++ 11 -w -nostdlib -nostartfiles -nostdinc -nodefaultlibs -fno-exceptions -std = c ++ 11 -g -D_QSYS_OS = _QSYS_MSW -DWIN32 = 1 -D_DEBUG = 1 -D_CONSOLE = 1 -I..\..\..\..\..\include -c D:\ Develop\workspace\CP\QOR1\Demo\ArchQOR\ArchQORDemo.cpp -o obj\Debug\Demo\ArchQOR \ArchQORDemo.o



mingw32-g ++。exe -L..\QORStrat1\bin\Debug -L..\WinUsrExeBoot -L..\WinCmpSupQORMinGW -o bin \Debug \ ArchQORDemo.exe obj \ Debug \Demo \ArchQOR \ArchQORDemo.o -nostdlib -Wl, - disable-runtime-pseudo-reloc -Wl, - disable-auto-import -Wl, - verbose -lWinCmpSupQORMinGW -lgcc -lWinUsrExeBoot -lQORStrata1 -lkernel32



哪个适合 - 应用程序b使用C ++ 11语法假设构建一个简单的一个cpp文件应用程序,没有异常并链接到自定义C ++支持库,libgcc和自定义运行时。 (是的,我确实必须破解规范文件才能使它执行此操作,但这不是问题)。



应用程序构建正常,自定义运行时QORStrata1.dll获取加载,调用,它是否成功初始化,包括进行Win32 API调用和返回,但是从未到达应用程序入口点_tMainCRTStartup。



它在ntdll中死于SIGSEGV !RtlInitializeContext。



我的自定义C ++支持库包含来自gcc 4.7.1源码的libsupc ++中的所有内容,它与我链接的4.7.1 libgcc相匹配我可以看到的唯一可以忽略的是对PE可执行文件的一些神奇的MinGW支持。



有没有人知道Windows可能是哪些部分或资源在RtlInitializeContext下的.exe中寻找?

例如我有一个IMAGE_LOAD_CONFIG_DIRECTORY32实例。我需要别的东西吗?



有没有人知道关于MinGW PE魔法以及在欺骗编译器使用它时我可能缺少什么/不使用它?



我没有链接到mingw或mingwex但链接工作意味着所有内容都被QORStrata1.dll覆盖,因为它应该是。



对不起,如果这有点模糊,但除了我可以构建一个有效的DLL但是一个EXE之外,我有点不知道到底出了什么问题。相同的支持代码甚至没有到达一垒。



更新: -



它可以根据WinDbg,它是一个ENTRY POINT问题,它正在达到.exe代码,但是执行_tMainCRTStartup以外的其他东西,然后立即退出并崩溃试图在退出时锁定堆。

I'm using CodeBlocks ( 12.11 rev 8629, SDK 1.13.14 ) to build a 32-bit Windows executable, ArchQORDemo.exe

The command line is as follows:-

mingw32-g++.exe -std=c++11 -w -nostdlib -nostartfiles -nostdinc -nodefaultlibs -fno-exceptions -std=c++11 -g -D_QSYS_OS=_QSYS_MSW -DWIN32=1 -D_DEBUG=1 -D_CONSOLE=1 -I..\..\..\..\..\include -c D:\Develop\workspace\CP\QOR1\Demo\ArchQOR\ArchQORDemo.cpp -o obj\Debug\Demo\ArchQOR\ArchQORDemo.o

mingw32-g++.exe -L..\QORStrat1\bin\Debug -L..\WinUsrExeBoot -L..\WinCmpSupQORMinGW -o bin\Debug\ArchQORDemo.exe obj\Debug\Demo\ArchQOR\ArchQORDemo.o -nostdlib -Wl,--disable-runtime-pseudo-reloc -Wl,--disable-auto-import -Wl,--verbose -lWinCmpSupQORMinGW -lgcc -lWinUsrExeBoot -lQORStrata1 -lkernel32

Which ammounts to - the app being a trivial one cpp file application built using C++11 syntax assumptions, with no exceptions and linked to a custom C++ support library, libgcc and a custom runtime. ( Yes I did have to hack the specs file to make it do this but that's not the problem ).

The app builds fine, the custom runtime QORStrata1.dll gets loaded, called, does it's init successfully including making Win32 API calls and returns but the application entry point, _tMainCRTStartup, is never reached.

It dies with a SIGSEGV in ntdll!RtlInitializeContext.

My custom C++ support library contains everything that's in libsupc++ from the gcc 4.7.1 sources which matches with the 4.7.1 libgcc I'm linking with so the only thing I can see that can be missing is some magic MinGW support for PE executables.

Does anyone out there know what sections or resources Windows may be looking for in my .exe under RtlInitializeContext?
For example I have a IMAGE_LOAD_CONFIG_DIRECTORY32 instance. Do I need something else?

Does anyone out there know anything about MinGW PE magic and what I might be missing in terms of tricking the compiler into using it/ not using it?

I'm not linking to mingw or mingwex but the link works which implies everything is covered by QORStrata1.dll as it should be.

Sorry if this is a bit vague but I'm a little clueless as to what exactly is wrong other than I can build a valid DLL but an EXE with the same support code isn't even getting to first base.

Update:-

It could be an ENTRY POINT issue, according to WinDbg it is reaching the .exe code but executing something other than _tMainCRTStartup and then immediately exiting and crashing trying to lock the heap on exit.

推荐答案

恐慌,这是一个切入点问题。使用--verbose on时,MinGW ld在报告事物链接缺失的入口点时很垃圾。

通过在命令行中添加-Wl,-e_mainCRTStartup并在link命令上包含supc ++替换两次来解决然后再次在bootstrap库之后你最终得到:



mingw32-g ++。exe -std = c ++ 11 -w -nostdlib -nostartfiles -nostdinc - nodefaultlibs -fno-exceptions -std = c ++ 11 -g -D_QSYS_OS = _QSYS_MSW -DWIN32 = 1 -D_DEBUG = 1 -D_CONSOLE = 1 -I..\..\..\..\ .. \include -c D:\Develop\workspace \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >


mingw32-g ++。exe -L..\QORStrat1\bin\Debug -L..\WinUsrExeBoot -L..\WinCmpSupQORMinGW -o bin \ Debug \ArchQORDemo.exe obj \Debug \ Demo \ArchQOR \ArchQORDemo.o -nostdlib -Wl, - disable-runtime-pseudo-reloc -Wl, - disable-auto-import -Wl, - v erbose -Wl,-e_mainCRTStartup -lWinCmpSupQORMinGW -lgcc -lWinUsrExeBoot -lWinCmpSupQORMinGW -lQORStrata1 -lkernel32
Panic over, it was an entry point issue. MinGW ld is rubbish at reporting things link missing entry points even with --verbose on.
Solved by adding -Wl, -e_mainCRTStartup to the command line and including the supc++ replacement twice on the link command, first and then again after the bootstrap library so you end up with:

mingw32-g++.exe -std=c++11 -w -nostdlib -nostartfiles -nostdinc -nodefaultlibs -fno-exceptions -std=c++11 -g -D_QSYS_OS=_QSYS_MSW -DWIN32=1 -D_DEBUG=1 -D_CONSOLE=1 -I..\..\..\..\..\include -c D:\Develop\workspace\CP\QOR1\Demo\ArchQOR\ArchQORDemo.cpp -o obj\Debug\Demo\ArchQOR\ArchQORDemo.o

mingw32-g++.exe -L..\QORStrat1\bin\Debug -L..\WinUsrExeBoot -L..\WinCmpSupQORMinGW -o bin\Debug\ArchQORDemo.exe obj\Debug\Demo\ArchQOR\ArchQORDemo.o -nostdlib -Wl,--disable-runtime-pseudo-reloc -Wl,--disable-auto-import -Wl,--verbose -Wl,-e_mainCRTStartup -lWinCmpSupQORMinGW -lgcc -lWinUsrExeBoot -lWinCmpSupQORMinGW -lQORStrata1 -lkernel32


这篇关于需要一些MinGW PE支持的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆