Need some MinGW PE-support support

Question

0.00/5 (No votes)

See more:

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.

Posted 1-Aug-13 1:40am

Matthew Faithfull

Updated 1-Aug-13 3:13am

v3

Add a Solution

Comments

pasztorpisti 1-Aug-13 10:43am

Even on the same linux machine I never link together object files produced by two different gcc compilers with different minor or major version number (for example using gcc 4.5 and 4.6 produced object files together probably sucks). A change in the minor version number can imply abi changes and you may be able to link together the object files but the binary is usually useless, has missing external dynamically loadable symbols and probably there are other errors too (of course it can manifest itself as a crash in mingw). You are too brave! :-)

Matthew Faithfull 1-Aug-13 10:50am

You're right of course, I don't think I'm doing that here. The only compiler I'm using is mingw-gcc 4.7.1 I'm just ripping it up to build things against my own runtime :-)

I've moved things on a step and am now hitting my code. It still crashes f course so more fun to be had.

pasztorpisti 1-Aug-13 11:28am

Then I simply misunderstood the problem, for some reason I assumed that the libs are coming from somewhere else as binary. Do you want to put together a minimalisitic exe with mingw? Once I did that with VS, only a few intrinsics have to be implemented. :-)

Matthew Faithfull 1-Aug-13 11:57am

"Do you want to put together a minimalisitic exe with mingw?"

Pretty close, I've developed my own runtime which works with VS, replaces MSVCRT/MSVCP. The next step is to make it work with MinGW GCC as a bridge to Linux GCC and because it's useful in itself. The next trick is to get static initialization to work. The runtime part I'm in control of but only if the compiler cooperates and puts everything in the right section. A very sharp stick may be required.

pasztorpisti 1-Aug-13 12:05pm

This is fun if you have the time. :-) I cheated by looking at the original crt. It was a shocking moment when I realized how how the static init/deinit works for C++ (init func pointer list in a specific segment, cooperation with the linker...) but its a very simple stupid good solution. :-) God knows how it is done with gcc, it can easily happen that similarly.

Matthew Faithfull 1-Aug-13 12:15pm

I'm hoping it's similar enough when both are building for Windows or I'll have to refactor things I'd rather not.
I have the MSVC static init working just fine although I'm not doing it exactly the same way they do, it is compatible. I suspect GCC uses different section names so I need to discover those and plug them in as compiler specifics.

pasztorpisti 1-Aug-13 12:16pm

Good luck, have fun! :-)

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Matthew Faithfull · Accepted Answer · 2013-08-01T04:47:00

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