Mingw-packages: gcc: DEP and ASLR not enabled by default

[salowenh]

The libgsf is flagged by tools such as BinSkim due to apparently not enabled safe exception handlers, DEP and ASLR security options.
Any thoughts on how to create a more secure compilation?

[Biswa96]

mingw-w64 gcc environment has many reputation of being flagged by anti virus programs. Search "mingw-w64 virus alert" and you will get many related issues. The alerts are mainly false positive which may not be related to disabled DEP and ASLR.

[salowenh]

@Biswa96 Unfortunately in this case I believe this is not a false positive as I can't see these flags in any of the binaries.
Do you have any reason to think otherwise?

[lazka]

Last time I looked gcc didn't support DEP and ASLR by default, maybe that has changed in the meantime. I'd certainly welcome it.

[salowenh]

@lazka support was added in gcc 10.1.0, it's indeed disabled by default (i'm not sure why)

[mati865]

@salowenh because various LD versions had problem with it.

[revelator]

Also gobject-introspection has problems with it, try enabling it and then watch what happens heh.

[revelator]

btw you can also pretty much forget using PCH if you enable ASLR and DEP they are incompatible as is.
Im not sure how microsoft got around this problem.

[jeremyd2019]

https://sourceware.org/bugzilla/show_bug.cgi?id=19011

I have no idea about GCC, but they're just flags on the PE file, controlled by the linker (ld). I actually looked at this a bit. You can turn the options on by default in a gcc spec file, but there is no corresponding negative option to turn them back off on a case-by-case basis. peflags.exe in the rebase package comes in handy in that case :wink:

[mati865]

@jeremyd2019 we can add flags in https://github.com/msys2/MSYS2-packages/blob/master/pacman/makepkg_mingw64.conf
Then all repo packages will have it enabled.

[lazka]

I've uncommented the LDFLAGS stuff and built ninja as a test:

Before:

Get-PESecurity -file C:\msys64\home\user\M\mingw-w64-ninja\pkg\mingw-w64-x86_64-ninja\mingw64\bin\ninja.exe

FileName         : C:\msys64\home\user\M\mingw-w64-ninja\pkg\mingw-w64-x86_64-ninja\mingw64\bin\ninja.exe
ARCH             : AMD64
DotNET           : False
ASLR             : False
DEP              : False
Authenticode     : False
StrongNaming     : N/A
SafeSEH          : N/A
ControlFlowGuard : False
HighentropyVA    : False

After:

Get-PESecurity -file C:\msys64\home\user\M\mingw-w64-ninja\pkg\mingw-w64-x86_64-ninja\mingw64\bin\ninja.exe

FileName         : C:\msys64\home\user\M\mingw-w64-ninja\pkg\mingw-w64-x86_64-ninja\mingw64\bin\ninja.exe
ARCH             : AMD64
DotNET           : False
ASLR             : True
DEP              : True
Authenticode     : False
StrongNaming     : N/A
SafeSEH          : N/A
ControlFlowGuard : False
HighentropyVA    : True

Looks like the last remaining upstream changes (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=dc9bd8c92af67947db44b3cb428c050259b15cd0) are in binutils 2.34, which we have.

Should we try enabling this by default? What about 32 bit?

[jeremyd2019]

Everything but high entropy va should work on 32-bit as well. MS tools actually let you set highentropyva on 32-bit modules, but ld doesn't, and I don't think it means anything there.

[lazka]

gtk3 works, python (which uses pgo/lto) segfaults at link time.

[mati865]

We should upgrade to binutils 2.35 first.

[jeremyd2019]

btw you can also pretty much forget using PCH if you enable ASLR and DEP they are incompatible as is.
Im not sure how microsoft got around this problem.

I wonder if @revelator meant PGO rather than PCH in that comment. I was scratching my head how these would break precompiled headers, but now that you saw they broke profile-guided optimization it makes perfect sense why that could be a problem.

[jeremyd2019]

Another option to consider adding to those that were commented out in makepkg_mingw64.conf would be to set the image base above 2^32. This appears to be the default for -cygwin (or -msys in this patch). Unfortunately, the default base for exes and dlls is supposed to be different, and it isn't known when setting LDFLAGS which is being built.

[mati865]

@jeremyd2019 appropriate bases for executables and libraries have to be set in those lines: https://github.com/bminor/binutils-gdb/blob/d262797294039fc828e36f76c45e462966c5c72a/ld/emultempl/pep.em#L102

[lazka]

I wonder if @revelator meant PGO rather than PCH in that comment.

The last time this was tried also mentions PCH: https://github.com/msys2/MINGW-packages/commit/2602139640f15fb6c58c11c83903f2f3f48b7f13#diff-c8386c579acf251c791f3c68b4d22e65

[jeremyd2019]

I was wondering why nobody had a patch for that binutils bug in all this time. 😕 Well, I finished mine and added to the bug in any event, maybe save the next guy some confusion.

[salowenh]

I was wondering why nobody had a patch for that binutils bug in all this time. 😕 Well, I finished mine and added to the bug in any event, maybe save the next guy some confusion.

Are you relating to the base address bug? can you please share how to apply it when compiling with mingw?

[jeremyd2019]

The base address was just one part of this. https://sourceware.org/bugzilla/show_bug.cgi?id=19011 has my two patches, one to provide options to turn off dll characteristics flags, and a second one to change the defaults. This second one does change the default on x86_64 to use base addresses greater than 2^32, using the same variation that was already in place for cygwin/msys. They could be applied in the PKGBUILD for binutils if desired.

It sounds though like this might open a can of worms.

[jeremyd2019]

The last time this was tried also mentions PCH

Ah, GCC puts pointers in their PCH output, so can't use it if gcc's base address changed. Sounds like this is a problem for everyone... https://bugzilla.redhat.com/show_bug.cgi?id=1721553#c34

[mati865]

If it still fails with 2.35 then there must be some other Binutils bug.
LLD always uses ASLR when targeting MSVC (and soon will enable it by default for MinGW: https://reviews.llvm.org/D86654) so it should work there without issues so it could be used for comparing broken binaries made with BFD.

[lazka]

for the python segfault, only --high-entropy-va makes it crash even without pgo/lto, with 2.35

[lazka]

So, as far as I understand, one way forward would be:

• uncomment what is there in makepkg_mingw64.conf
• ~maybe patch binutils move_default_addr_high~
• for packages breaking, set LDFLAGS in their PKGBUILD and add a comment why
• ... see how things go with package updates in CI

edit: ~also add --disable-auto-image-base~
edit2: patch NT_EXE_IMAGE_BASE and NT_DLL_IMAGE_BASE to match msvc when 64 bit

[mati865]

maybe patch binutils move_default_addr_high

This sets image base to special ones used by Cygwin. If we are going to change it then we should patch BFD to use the same address as MSVC and LLD. Then try if Python still crashes.

[lazka]

(I don't know how any of this works, so I don't understand the details.. as for python, to clarify, the linking process crashes, not python)

edit: ah, I see, that options is for cygwin, which uses other default addresses.

[jeremyd2019]

I didn't see a need to --disable-auto-image-base - I don't think it would hurt anything if ASLR is enabled, and could be helpful if something needs to disable ASLR (though I guess they could re-enable it if they needed to)

[jeremyd2019]

maybe patch binutils move_default_addr_high

This sets image base to special ones used by Cygwin. If we are going to change it then we should patch BFD to use the same address as MSVC and LLD.

I didn't notice this, thanks. I guess I should update my patch to do this too. 0x1 4000 0000 for EXEs and 0x1 8000 0000 for DLLs? That kind of makes move_default_addr_high a misnomer 😁

[lazka]

I didn't see a need to --disable-auto-image-base - I don't think it would hurt anything if ASLR is enabled, and could be helpful if something needs to disable ASLR (though I guess they could re-enable it if they needed to)

looking at the code it seems it's disabled by default anyway. Not sure why it was suggested in the bug report you linked, hm.

[mati865]

the linking process crashes, not python

Oh that's interesting, hopefully you've got the backtrace. Linker crash should be easier to deal with than miscompiled binary.

looking at the code it seems it's disabled by default anyway.

AFAIK it's disabled in Binutils 2.34+ if ASLR is enabled.

0x1 4000 0000 for EXEs and 0x1 8000 0000 for DLLs?

Yes.

[jeremyd2019]

It's (--enable-auto-image-base) enabled by the GCC specs.
https://github.com/gcc-mirror/gcc/blob/85847fd421d7760f45f0e69c7ae3607f2f898bb8/gcc/config/i386/mingw-w64.h#L98

[revelator]

Aye i ment PCH but it is interresting that it also affects PGO.

Looking on with baithed breath if this can be fixed it would be great.

[mati865]

@jeremyd2019 then we should patch GCC as well.

[jeremyd2019]

Can you explain why that's necessary? ISTM that the image base address doesn't matter when ASLR is enabled (except for the special case where it's > 2^32 on x64), so it shouldn't matter whether it's on or off. However, if ASLR is disabled, it would still be as beneficial as ever to not have conflicting addresses requiring the legacy relocation behavior.

[mati865]

@jeremyd2019 disabling is not necessary but auto image base was confusing people who were inspecting binaries.
Disabled ASLR is valid argument so we can leave it as is for now.

[jeremyd2019]

It looks like my patches were accepted by binutils. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=514b4e191d5f46de8e142fe216e677a35fa9c4bb

[jeremyd2019]

The libgsf is flagged by tools such as BinSkim due to apparently not enabled safe exception handlers, DEP and ASLR security options.

SafeSEH has got me going around in circles. Does anybody here know anything about SEH in MinGW-w64? I'm not comfortable setting --no-seh by default, but I have read that GCC doesn't support SEH anyway. If true, it may be a good candidate to set in the default spec in GCC.

[mati865]

SafeSEH exists only for 32 bit x86 for which we are using Dwarf-2 unwinding. In MinGW mode LLD already sets IMAGE_DLL_CHARACTERISTICS_NO_SEH for ARMv7 and i686.

[jeremyd2019]

SafeSEH exists only for 32 bit x86 for which we are using Dwarf-2 unwinding. In MinGW mode LLD already sets IMAGE_DLL_CHARACTERISTICS_NO_SEH for ARMv7 and i686.

That sounds like a recommendation to add --no-seh to the makepkg_mingw32 hardened LDFLAGS at least.

[revelator]

hmm still seing some packages fail to build with aslr hardening on for one gobject-introspection.
The --no-seh flag also applies to sjlj i suspect ?.

[jeremyd2019]

I believe the plan is to identify failing packages, and disable the responsible flag(s) on them on a case-by-case basis, so please share them.
I am not very confident in my understanding of the --no-seh stuff, but I am pretty sure that neither dwarf2 nor sjlj require SEH.

[revelator]

Ok then i can report capnproto and openshadinglanguage also fails when this is enabled (segfault).
Atm im trying to rebuild gcc with aslr and dep on to see if it breaks.

Aye i was under the same impression with sjlj, i use this exception model locally though not as fast as dwarf i found it to be more stable. A 32 bit SEH exception model for gcc would be nice but noone seems to be working on it atm.

[jeremyd2019]

I did try gcc last night, and found that the final binaries produced did not have the new flags set. It appears gcc does not apply the LDFLAGS to later stages (it looked like it was using it at the beginning of the build, so it may have been only on stage1)

[revelator]

Ok odd mine segfaults halfway into building libiberty using LDFLAGS="-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--no-seh"

[jeremyd2019]

Couple of things: 1) I only tried i686, not x86_64, and 2) I do not think that --no-seh should be set on x86_64.

[revelator]

Yeah if i remember correctly you need to use the stage CFLAGS LDFLAGS to get the compiler to pick it up in last stage else it defaults to it's internal flags.

[revelator]

Probably not if i used the official builds from here :) but im using a deriative using sjlj exceptions for both 32 and 64 bit.

[revelator]

Hmm this is weird i tried using the old method with LDFLAGS="-pipe -Wl,--enable-auto-image-base,--no-seh"
and this works fine so far ?!?. Ill let it run to completion to see if there will be trouble down the line.

[revelator]

Old method worked fine with --no-seh for both 64 and 32 bit.
I decided to rebuild my compiler with alex patches 0300-default-secure-pe-flags.patch and 0310-reproducible-import-libraries.patch merged with the 0320-aslr-compat-base-addr.patch from latest pull and it works so far though im not completely sure about the fallthrough added in OPTION_DYNAMIC_BASE and OPTION_HIGH_ENTROPY_VA should also apply to the flags to set them to off. This has the added benefit that binutils will force aslr and dep by default even in bootstrapped gcc but it becomes interresting if it will also still break pch.

[revelator]

internal compiler error in avx2intrin.h so nope gcc is not happy, also dosnt matter which gcc compiler is used as i tried both the official and my own and they both throw this error while building gcc-9.3.0.
Also it seems we need an extra flag -> --enable-reloc-section in LDFLAGS as well as the other flags.
Atm im trying a non bootstrap gcc build to see if it triggers it again with the above flag added.

[salowenh]

@jeremyd2019 can you please share how I can use your changes to build? I've pulled the latest master yet I don't see a new msys build

[revelator]

Only a new patch was added im not sure a rebuild has taken place yet as you need all dependant libraries to also be linked with aslr support. For binutils we need iconv and zlib rebuilt with aslr and gcc need's gmp isl mpfr mpc iconv and gettext i think.
Im doing a rebuild atm of those to see if things break and in that case on what. So it will probably take some time before any packages with this enabled are avaliable since we are testing stuff atm.

[salowenh]

@revelator thanks for the quick reply. I'm ok with building the packages myself but it sounds like waiting will be smarter as issues may rise.
Just for general understanding, any idea how long these issues usual takes? days/weeks/months/era 😉 ?

[revelator]

probably not that long ;) i just finished rebuilding my compiler and dependencies and no problems so far.
But there are a lot of other packages to check so something might turn up.

Next goal will be bootstrapping gcc with aslr and dep enabled with my newly built compiler and dependencies and then see where it takes me.

Then if nothing breaks i will try to build gobject introspection with aslr and dep as that one has allways had problems with it enabled before.

[revelator]

Well gcc itself does not like being built with aslr ...

x86_64-w64-mingw32-g++ -std=gnu++98 -g -D__USE_MINGW_ACCESS -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -pipe -Wl,--enable-reloc-section -Wl,--stack,12582912 -no-pie -o build/genmddeps.exe \ build/genmddeps.o build/read-md.o build/errors.o ../build-x86_64-w64-mingw32/libiberty/libiberty.a build/genmddeps.exe ../../gcc-9.3.0/gcc/common.md ../../gcc-9.3.0/gcc/config/i386/i386.md > tmp-mddeps /bin/sh: linje 1: 30585 Segmentation fault build/genmddeps.exe ../../gcc-9.3.0/gcc/common.md ../../gcc-9.3.0/gcc/config/i386/i386.md > tmp-mddeps

the flags are different because my newly built binutils defaults to aslr + dep so no need for the extensive list in LDFLAGS.
Sadly while i could build all the dependencies gcc itself fails to bootstrap with the above error.

[jeremyd2019]

I decided to rebuild my compiler with alex patches 0300-default-secure-pe-flags.patch and 0310-reproducible-import-libraries.patch merged with the 0320-aslr-compat-base-addr.patch from latest pull and it works so far though im not completely sure about the fallthrough added in OPTION_DYNAMIC_BASE and OPTION_HIGH_ENTROPY_VA should also apply to the flags to set them to off. This has the added benefit that binutils will force aslr and dep by default even in bootstrapped gcc but it becomes interresting if it will also still break pch.

Those patches are not complete/sufficient. I just made a draft PR with the upstream patches cherry-picked if you would like to test with binutils with the new patches.

[jeremyd2019]

Only a new patch was added im not sure a rebuild has taken place yet as you need all dependant libraries to also be linked with aslr support.

I don't think you do. Each image (DLL or EXE) can be aslr or not, and there can be both in a process.

[revelator]

Hmm not from what i read but maybe they are wrong ?.
Sure let me test it out :) so far i had no luck building either of binutils nor gcc with aslr and dep but several other packages build with no problem. So far i built libiconv gettext ncurses libtre libsystre winpthreads zlib bzip2 gmp isl mpfr and mpc without any problems with aslr and dep enabled.

I also implemented a more complete version of dlopen and friends from dlfcn-win32 for plugin support (works like a charm).
Worst parts was figuring out where to yank in the psapi library as it needs that for enumerating process modules, it got a little hacky adding that but i could not find any autoconf varible specifically geared to handle this.

[jeremyd2019]

Hmm not from what i read but maybe they are wrong ?.
Sure let me test it out :) so far i had no luck building either of binutils nor gcc with aslr and dep

Huh. GCC worked for me. I just successfully built mingw-w64-i686-python with gcc built with my #6899 patch to all gcc itself was built with the flags (minus ada libs).

[jeremyd2019]

I build the same list of packages you gave: libiconv gettext ncurses libtre-git libsystre winpthreads-git zlib bzip2 gmp isl mpfr mpc. Of these winpthreads didn't seem to take the LDFLAGS (so didn't have no-seh set). isl mpc and mpfr had no dlls or exes so there was no point in rebuilding those for these flags, which only apply to those. As always, this was all i686.

[jeremyd2019]

I rebuilt binutils and am currently building gcc. Using process explorer I set lower pane view to DLLs and turned on the ASLR, base, and image base columns. The only DLL I see in xgcc/cc1plus that is not ASLR is libzstd.dll. So far everything I've tried has worked for me on i686.

[revelator]

bug in gcc-9.3.0 maybe ? im still using the previous version.

[revelator]

so far i only tried building the x86_64 version, ill try with the i686 version next but it should have worked on either i reckon.

[revelator]

im at a loss... it simply does not work here :/

gcc is now wholly unable to find the crt, it crashes on avx512 instructions im not even able to rebuild the crt.
Had to revert all the changes and call it a day.

It might have something to do with me using TDM's patchset for gcc which defaults it to using the static runtimes.
I can build most other packages with aslr and dep though.

[mati865]

@revelator you also need patched binutils.

[revelator]

I know :) still unable to build gcc with aslr so im out of ideas.

[revelator]

Going to use a really old gcc (4.8.1) to bootstrap gcc-9.3.0 with aslr on. Just hope some of the later changes to binutils like the ctor changes dont wreak it. This time ill try without the TDM patchset but im not holding my hopes up just yet.

[revelator]

Nope still not possible to build gcc with aslr.

D:/mingw-w64-gcc/src/build-x86_64-w64-mingw32/gcc/include/avx512fintrin.h:15958:3: internal compiler error: Segmentation fault 15958 | __A = _mm512_mask_mov_ps (_mm512_set1_ps (1.0f), __U, __A);

Same place again and this time building gcc-10.2.0.
Either something is horribly wrong with that avx function or i have no idea whats causing this.

[jeremyd2019]

GCC finished building fine for me. rebuild zstd as well to get everything gcc loads to be aslr, and that worked fine too. It looks like ICU doesn't take the LDFLAGS, but because I'm running the binutils with the updated defaults that just means --no-seh is not set (but for those attempting to test without binutils with new defaults, that would matter).

[revelator]

now im getting that error without setting aslr and dep even with Msys2 from the official installer Oo what on earth is going on.

[revelator]

There was actually a bug in the compiler intrinsics...

extern __inline double __attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) _mm512_mask_reduce_mul_pd (__mmask8 __U, __m512d __A) { /* The intrinsics for _mm512_set1_pd must not have decimals behind */ __A = _mm512_mask_mov_pd (_mm512_set1_pd (1.0 <- yes this one), __U, __A); __MM512_REDUCE_OP (*); }

and another for float values, after removing the decimal after 1 it compiles cleanly again.
Looks like some recent changes to one of the dependencies now trigger a compiler fault on these functions.

[jeremyd2019]

It looks like ICU doesn't take the LDFLAGS, but because I'm running the binutils with the updated defaults that just means --no-seh is not set (but for those attempting to test without binutils with new defaults, that would matter).

looks like boost should be added to the list of packages that don't take LDFLAGS also.

For the record, #6899 and #6907 include a commit to make GCC respect LDFLAGS in later stages and in 'target' binaries, and differ in two different workarounds to disable dynamicbase on the GCC backends so PCH works again.

[revelator]

Aye noticed you added more patches, trying them out now though i had to revert my build environment to an older version cause something has completely broken this one (throws internal compiler errors on everything).

[revelator]

Ok i think i found the problem breaking my builds.
my bootstrap compiler used older versions of winpthreads gmp isl mpfr and mpc which caused the internal compiler errors when i updated my bootstrap compiler with it. Had to copy the old dll dependencies to where cc1.exe is located then bootstrap the compiler linking to the new gmp to hopefully get a working compile (atleast it is still building).

[revelator]

Yep that was it i just updated gmp on my working bootstrap compiler and gcc goes boom :S

[jeremyd2019]

There was actually a bug in the compiler intrinsics...

extern __inline double __attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) _mm512_mask_reduce_mul_pd (__mmask8 __U, __m512d __A) { /* The intrinsics for _mm512_set1_pd must not have decimals behind */ __A = _mm512_mask_mov_pd (_mm512_set1_pd (1.0 <- yes this one), __U, __A); __MM512_REDUCE_OP (*); }

and another for float values, after removing the decimal after 1 it compiles cleanly again.
Looks like some recent changes to one of the dependencies now trigger a compiler fault on these functions.

https://github.com/msys2/MINGW-packages/pull/6907/checks?check_run_id=1068095373#step:5:5741

Whoops!

[jeremyd2019]

Well that worked around that segfault, but now crashing trying to compile __mulxc3. Something is really screwy on x86_64.

[jeremyd2019]

I tried undoing the various changes to binutils options until I found what was causing this. Even without the patch to avx512fintrin.h, the build has gotten past the stage1 libgcc by setting --image-base=0x400000. This of course would suck if applied to any DLLs. My previous experimentation showed that these flags get applied to only one DLL, liblto_plugin-0.dll. I'll have a look and see if I can do something about that.

[revelator]

indeed i saw the same as the compile moved on.

ugh i had a hunch that it might relate to the lto plugin... could it be caused by the dlsym wrapper mechanism ? since i have a feeling this might balk out if it cannot read the base adress.

[jeremyd2019]

no, the crash is not related to LTO plugin... what the LTO plugin is doing now is making me have to try to come up with a workaround just for it

[revelator]

Got plenty confusing indeed with the various build errors, some seemed related to the dependency libraries others where just plain confusing like the avx512 error (since i had no problems compiling it with earlier binutils, but even downgrading it to the privious release ended up throwing the same error so i was like WTF).

But seems you have an idea about what might be causing it so ill let you work.

[jeremyd2019]

Yeah, I found a configure argument that should do what I want, but I'm in quoting hell right now trying to figure out what combination of quotes and escapes will get the string I want through to where I want it 😬

[revelator]

maybe alex or one of the other members got an idea for that ?.

[jeremyd2019]

Think I've got it. Hopefully https://github.com/msys2/MINGW-packages/pull/6907/commits/1c41e8edde85426dae4a2c6a651e2836816a00e5 does the trick. I couldn't get any quoting passed through to do what I wanted, so ultimately just escaped the spaces in LDFLAGS. This also happens to be the way the GCC docs demonstrate using this configure option (but for setting CC rather than LDFLAGS).

[jeremyd2019]

BTW, the only reason the base address should cause GCC crashes is what Microsoft referred to as 'latent pointer truncation issues'. So there's a bug somewhere in GCC, and this is just hiding it again.

[revelator]

ouch thats a nasty one...

[revelator]

got past stage 1 with the new build options though strangely stage 1 had aslr and dep disabled it is now running stage 2 which seems to have it enabled so im curious to see what happens when it hits libgcc since that is where the trouble seems to start.

[revelator]

stage 2 has succeded going for the home stretch 👍 hope to god there will be no further whoopsies down the lane.
curious if it will still break gobject introspection.

[revelator]

agh libada segfaulted in the last stage, might be because i let the jobserver run with more than one core TDM gcc does not like that very much when bootstrapping gcc so ill have to do it all over again with make -j1 to make sure.

[revelator]

Well it still crashes building gnat tools so theres a bit more work needed i reckon.

make[3]: Går til katalog "/G/mingw-w64-gcc/src/build-x86_64-w64-mingw32/gcc/ada/tools" rm -f tools/* rm -rf tools mkdir -p tools (cd tools; ln -s ../sdefault.adb ../snames.ads ../snames.adb .) rm -f tools/indepsw.adb; ln -s /G/mingw-w64-gcc/src/gcc-9.3.0/gcc/ada/indepsw-gnu.adb tools/indepsw.adb; touch ../stamp-tools ../../gnatmake -j0 -c -b -I- -I../rts -I. -I/G/mingw-w64-gcc/src/gcc-9.3.0/gcc/ada \ --GNATBIND="../../gnatbind" --GCC="../../xgcc -B../../ -g -march=x86-64 -mtune=generic -O2 -pipe -W -Wall -gnatpg -gnata" \ gnatchop gnatcmd gnatkr gnatls gnatprep gnatxref gnatfind gnatname \ gnatclean -bargs -I- -I../rts -I. -I/G/mingw-w64-gcc/src/gcc-9.3.0/gcc/ada -static -x make[3]: *** [../gcc-interface/Makefile:438: common-tools] Segmentation fault make[3]: Forlader katalog "/G/mingw-w64-gcc/src/build-x86_64-w64-mingw32/gcc/ada/tools" make[2]: *** [Makefile:197: gnattools-native] Fejl 2 make[2]: Forlader katalog "/G/mingw-w64-gcc/src/build-x86_64-w64-mingw32/gnattools" make[1]: *** [Makefile:14037: all-gnattools] Fejl 2 make[1]: Forlader katalog "/G/mingw-w64-gcc/src/build-x86_64-w64-mingw32" make: *** [Makefile:1006: all] Fejl 2

the other libs seem to compile fine.

[jeremyd2019]

Huh, it built in CI... But, I have found that most gnat tools are built with LDFLAGS_FOR_TARGET rather than LDFLAGS/--with-boot-ldflags, so they would still be having the high base address.

[revelator]

it went pretty far here also (bootstrap done) but crashed both times at the same place in gnattools.
Yeah i also noted that the executables had nxcombat and high entropy set but no aslr :S might be nice to get the gcc devs in over this one as well so we can avoid to many hacks.

[revelator]

And sorry if some of the messages look odd (im danish) and gettext (correctly) changed the compiler languages to that.

[jeremyd2019]

Yeah i also noted that the executables had nxcombat and high entropy set but no aslr :S

That shouldn't happen. The binutils will turn off high-entropy-va if dynamicbase is set, and will turn dynamicbase on if high-entropy-va is set.

[revelator]

Aye its pretty weird but that was what peviewer told me.

[revelator]

Hmm seems depot-tools and miktex together made some ugly broken environment i removed both and it builds normally now.
Kinda sad though cause with miktex sourced i could build all documentation in gcc binutils and pretty much 90% of any other package.

[revelator]

spoke to soon gcc bootstrap still aint working not even if i revert the dep and aslr changes to binutils-2.35 internal compiler error galore. Not sure how but this experiment has rendered my compiler unusable i cannot build even the simplest things anymore.
i even tried bootstrapping gcc on the official compiler and while it builds there as soon as i install it everything breaks again Oo.

[jeremyd2019]

I have no idea what's going on with your env 😕 The internal compiler errors seemed to be solved for me by changing the base address of the gcc executables back down below 4GB.

[mati865]

@jeremyd2019 this might be the same issue as in https://github.com/msys2/MINGW-packages/pull/6932#issuecomment-688233761
Does GCC use dllimport/dllexport for its own code?

[jeremyd2019]

Could be. I have no idea what GCC does.

[revelator]

Finally fixed my compiler back to its original state (not easy), basically i had to build a gcc-4.9.2 cross compiler first to bootstrap gcc-9.3.0 with TDM's patches, this turned up some interresting things that basically means i cannot ever hope to use aslr as long as i use the TDM based patchset. TDM uses sortof a hack to get shared memory pointers to allow throwing exceptions across dll boundaries even if linked to the static runtimes. Sadly this mechanism changes libgcc's internals as the code wraps certain calls and is therefore no longer wholly compatible with main unmodified gcc (example some libgcc internals wraps with an _shmem prefix).
While this behaviour only reflects on the static runtimes and does not seem to be exported to any library built against it, the reality is that the shared memory interface relies on set base addresses and goes bonkers if those change randomly as it does with aslr.

non aslr executables and libraries are still useable with normal mingw-w64-gcc though.
Well it would have been nice if it where possible since that would also take care of me having to whitelist gcc with different AV solutions but it seems this is not to be.

[jeremyd2019]

I knew there was something odd about your env 😀 3rd party patches that I'm not seeing...

[revelator]

Well the idea was nice if it had worked, codeblocks still uses the TDM compilers to create executables that are as close to the windows environment as possible without having to rely on the gcc runtime for anything but internals. And my build environment was pretty much based around codeblocks with msys2 as a package manager for a TDM based build. Besides my mingw64 environment being different by using sjlj exceptions my msys2 also uses a slightly different and some might say outdated sgml docbook format based around openjade because it plays nicer with latex (more tested). In fact i can build any doc format for any package. Aslr would have been a nice addition but as you seen it wont work with my environment, dep is still solid though it probably wont keep pesky AV solutions quiet.

[revelator]

Hmm with the latest binutils i can build gcc if i disable gnat, if i dont disable it the gnat tool binaries will segfault.
So seems it was not the shared memory patch causing this, but i suspect some of TDM's other patches might do something
weird to gnat. Atm there are only 2 gnat specific patches one aims to fix unicode support for gnat the other aims to fix windows socket support for it. These two look a bit fishy and might have been intended for a mingw.org build so im going to try and remove them to see if things get anywhere.

[jeremyd2019]

The current state of affairs in the mingw-w64-binutils package is that all of the options (higher image base, dynamicbase, etc) are disabled by default, and are enabled in makepkg_mingw{32,64}.conf for packages.

[revelator]

Aye i noticed, it also works fine with my compiler if i disable the hardening flags but enabling it causes some packages to fail building like clang / gcc etc.
The gnat patches from TDM made no difference still segfaults in gnattools even if i remove them if hardening is enabled.
So next im going to remove the shared memory patch and see if this makes any difference, i suspect it might since this patch was backported from a very old 32 bit only gcc (3.4.5), and might not play to nice with 64 bit compiles though it works as long as i dont enable hardening.

[revelator]

Damn it was the shared memory patch that breaks aslr :/ after removing it gcc builds with aslr on with no problem.
So if i want hardening i will have to live with not being able to throw exceptions across dll boundaries or fix the patch to correctly remap the adresses (hint TDM's patch uses atomic pointers instead of memory mapping for this) so im not even sure how to do this.

[revelator]

Hmm the default flags in makepkg-mingw* breaks building clang (unknown linker flag --default-image-base-high) which causes anything after clang itself to fail building with an error since ldd seems to not know this flag (maybe relegate this flag to PKGBUILD untill ldd supports it or atleast ignores it).

gcc seems to work fine after i removed the shared memory patch though it also seems to have gone a bit wonky on reliably building some packages (btw why was plugin support disabled ? it works here).

[mati865]

Hmm the default flags in makepkg-mingw* breaks building clang (unknown linker flag --default-image-base-high)

LLD doesn't understand that option, I'll open PR with upgrade to version 11 and fix for that flag later today/tomorrow.

[revelator]

Sounds good :)

[jeremyd2019]

@revelator I think there are different makepkg config files for clang.

@mati865 I never did send the patch adding that flag upstream to binutils. I had hoped it was just a temporary workaround while we got the bugs ironed out.

[mati865]

@jeremyd2019 I don't plan to upstream LLD patch either.

[revelator]

Hmm but if i use the makepkg config files for clang does it even build ? seing as there is no compiler present by default in the clang dirs.

I could symlink gcc to the clang dirs to get the compile going and remove the symlinks afterwards before installing clang if that is what is intended.

I understand it might just have been a temporary solution, and its quite easy to get around if unsetting LDFLAGS in the PKGBUILD script just before clang takes over compiling libc++ libc++abi libunwind etc. then set LDFLAGS to the same hardening options minus the problematic flag. What im not clear on is does lld push the base address high by default on 64 bit builds ?.

Here is what i do ->

# Use newly built compiler because GCC/binutils doesn't play nicely export CC="${srcdir}/build-${CARCH}/bin/clang" export CXX="${srcdir}/build-${CARCH}/bin/clang++" # ldd does not understand --default-image-base-high lets hope it atleast does the correct thing here. unset LDFLAGS if [ "${CARCH}" = "x86_64" ]; then export LDFLAGS="-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat" else export LDFLAGS="-pipe -Wl,--dynamicbase,--nxcompat,--no-seh,--large-address-aware" fi

[jeremyd2019]

sounds reasonable. I believe that @mati865 said that was the default in lld. You could verify an executable/dll's base with rebase -i

[revelator]

Well if it is the default behaviour of ldd i guess im safe.
Feel free to use my little hack for clang untill things get sorted out with binutils.

[revelator]

codelite plugins seem to not like it to much -> terminate called after throwing an instance of 'wxSQLite3Exception'
disabling plugins allows it to load. If compiled without aslr it works just fine with or without plugins.

[revelator]

still having problems with gobject-introspection also, non zero return error.
disabling aslr and dep allows it to work sadly anything relying on it can also not have this enabled :S.
So in essence anything related to glib...

Fixed TDM's shared memory patch, turned out it was an error on my part as the function needs to have exceptions disabled, i got wise some time back and changed the way it normally disabled exceptions by using #pragma GCC optimize "no-exceptions" unfortunatly while this works i forgot to reset it for the rest of the libgcc build.
sadly the pragmas in gcc are rather undocumented which is a shame as they can do more than most would expect.

[revelator]

--nxcompat works for gobject-introspection --dynamicbase does not ugh...

and while gcc now builds i found out that it is broken even with the fix to exceptions so i had to remove the shared memory patch for now. It seems to work somewhat reliable without it but i guess problems might crop up downhill.

added LDFLAGS+=" -Wl,--disable-dynamicbase" to gobject-introspection and a whole ballpark of other packages that rely on it so no aslr for these but atleast i get DEP support.

I have a feeling that it will newer work fully with statically linked runtimes like my version of gcc defaults to so i can either bite the apple and just revert the TDM changes or i will have to live with some packages that wont have ASLR.

[revelator]

Btw. ld from binutils-2.35.1 reports two instances of some features.

Alternativer: -a N�GLEORD Styrelse af delte biblioteker for kompatibilitet med HP/UX -A ARK, --architecture ARK S�t arkitektur -b M�L, --format M�L Angiv m�l for f�lgende inddatafiler -c FIL, --mri-script FIL L�s l�nkerskript i MRI-format -d, -dc, -dp Tving f�lles symboler til at v�re definerede --dependency-file FIL Write dependency file --force-group-allocation Force group members out of groups -e ADRESSE, --entry ADRESSE S�t startadresse -E, --export-dynamic Eksport�r alle dynamiske symboler --no-export-dynamic Undo the effect of --export-dynamic --enable-non-contiguous-regions Enable support of non-contiguous memory regions --enable-non-contiguous-regions-warnings Enable warnings when --enable-non-contiguous-regions may cause unexpected behaviour -EB L�nk objekt som er big-endian -EL L�nk objekt som er little-endian -f DELBIBL, --auxiliary DELBIBL Ydre filter for symboltabel over delte objekter -F DELBIBL, --filter DELBIBL Filter for symboltabel over delte objekter -g Ignoreret -G ST�RRELSE, --gpsize ST�RRELSE Lille datast�rrelse (hvis ingen st�rrelse, samme som --shared) -h FILNAVN, -soname FILNAVN S�t internt navn p� delt bibliotek -I PROGRAM, --dynamic-linker PROGRAM S�t PROGRAM som den dynamiske l�nker der bruges --no-dynamic-linker Produce an executable with no program interpreter header -l BIBLNAVN, --library BIBLNAVN S�g efter biblioteket BIBLNAVN -L KATALOG, --library-path KATALOG Tilf�j KATALOG til bibliotekss�gestien --sysroot=<DIRECTORY> Override the default sysroot location -m EMULERING S�t emulering -M, --print-map Vis tabelfil p� standard ud -n, --nmagic Just�r ikke data efter lige sider -N, --omagic Just�r ikke data efter lige sider, g�r ikke teksten kun l�sbar --no-omagic Just�r data efter lige sider, g�r ikke teksten kun l�sbar -o FIL, --output FIL S�t uddatafilnavnet -O Optim�r uddatafil --out-implib FIL Generate import library -plugin PLUGIN Load named plugin -plugin-opt ARG Send arg to last-loaded plugin -flto Ignored for GCC LTO option compatibility -flto-partition= Ignored for GCC LTO option compatibility -fuse-ld= Ignored for GCC linker option compatibility --map-whole-files Ignored for gold option compatibility --no-map-whole-files Ignored for gold option compatibility -Qy Ignoreret for kompatibilitet med SVR4 -q, --emit-relocs Generate relocations in final output -r, -i, --relocatable Gener�r relok�rbart uddata -R FIL, --just-symbols FIL L�nk kun symboler (hvis katalog, samme som --rpath) -s, --strip-all Fjern alle symboler -S, --strip-debug Fjern fejls�gningssymboler --strip-discarded Strip symbols in discarded sections --no-strip-discarded Do not strip symbols in discarded sections -t, --trace Udskriv fil�bninger -T FIL, --script FIL L�s l�nkerskript --default-script FIL, -dT L�s forvalgt l�nkerskript -u SYMBOL, --undefined SYMBOL Begynd med udefineret reference til SYMBOL --require-defined SYMBOL Require SYMBOL be defined in the final output --unique [=SEKTION] Flet ikke [SEKTION | for�lderl�se] sektioner -Ur Byg globale konstruktors-/destruktorstabeller -v, --version Vis versionsinformation -V Vis versions- og emuleringsinformation -x, --discard-all Smid alle lokale symboler v�k -X, --discard-locals Smid tempor�re lokale symboler v�k (standard) --discard-none Smid ikke nogen lokale symboler v�k -y SYMBOL, --trace-symbol SYMBOL Udskriv omtale af SYMBOL -Y S�GESTI Standards�gesti for Solaris-kompatibilitet -(, --start-group Start en gruppe -), --end-group Slut en gruppe --accept-unknown-input-arch Accept input files whose architecture cannot be determined --no-accept-unknown-input-arch Reject input files whose architecture is unknown --as-needed Only set DT_NEEDED for following dynamic libs if used --no-as-needed Always set DT_NEEDED for dynamic libraries mentioned on the command line -assert N�GLEORD Ignoreret for SunOS-kompatibilitet -Bdynamic, -dy, -call_shared L�nk mod delte biblioteker -Bstatic, -dn, -non_shared, -static L�nk ikke mod delte biblioteker -Bsymbolic Bind globale referencer lokalt -Bsymbolic-functions Bind globale funktionsreferencer lokalt --check-sections Kontroll�r sektionsadresser for overlapninger (standard) --no-check-sections Kontroll�r ikke sektionsadresser for overlapninger --copy-dt-needed-entries Copy DT_NEEDED links mentioned inside DSOs that follow --no-copy-dt-needed-entries Do not copy DT_NEEDED links mentioned inside DSOs that follow --cref Opret krydsreferencetabel --defsym SYMBOL=UDTRYK Defin�r en symbol --demangle [=STIL] Afkod symbolnavn [brug STIL] --disable-multiple-abs-defs Do not allow multiple definitions with symbols included in filename invoked by -R or --just-symbols --embedded-relocs Gener�r indlejrede relokeringer --fatal-warnings Behandl advarsler som fejl --no-fatal-warnings Behandl ikke advarsler som fejl (forvalgt) -fini SYMBOL Kald SYMBOL ved udl�sning --force-exe-suffix Tving generering af fil med endelsen .exe --gc-sections Fjern ubrugte sektioner (p� visse m�l) --no-gc-sections Fjern ikke ubrugte sektioner (standard) --print-gc-sections List removed unused sections on stderr --no-print-gc-sections Do not list removed unused sections --gc-keep-exported Keep exported symbols when removing unused sections --hash-size=<NUMBER> Set default hash table size close to <NUMBER> --help Vis hj�lp om flag -init SYMBOL Kald SYMBOL ved indl�sning -Map FILE/DIR Write a linker map to FILE or DIR/<outputname>.map --no-define-common Defin�r ikke f�lles lagring --no-demangle Afkod ikke symbolnavne --no-keep-memory Brug mindre hukommelse og mere disk-I/O --no-undefined Do not allow unresolved references in object files --allow-shlib-undefined Allow unresolved references in shared libraries --no-allow-shlib-undefined Tillad ikke ul�ste referencer i delte biblioteker --allow-multiple-definition Tillad flere definitioner --no-undefined-version Forbyd udefineret version --default-symver Create default symbol version --default-imported-symver Create default symbol version for imported symbols --no-warn-mismatch Advar ikke om uparrede inddatafiler --no-warn-search-mismatch Don't warn on finding an incompatible library --no-whole-archive Deaktiv�r ---whole-archive --noinhibit-exec Opret en uddatafil ogs� hvis fejl forekommer -nostdlib Brug kun bibliotekskataloger som angives p� kommandolinjen --oformat M�L Angiv m�l for uddatafil --print-output-format Print default output format --print-sysroot Print current sysroot -qmagic Ignoreret for kompatibilitet med Linux --reduce-memory-overheads Reduce memory overheads, possibly taking much longer --relax Reduce code size by using target specific optimizations --no-relax Do not use relaxation techniques to reduce code size --retain-symbols-file FIL Behold kun symboler angivne i FIL -rpath S�GESTI S�t k�rselstidss�gesti for delte biblioteker -rpath-link S�GESTI S�t l�nkningstidss�gesti for delte biblioteker -shared, -Bshareable Opret et delt bibliotek -pie, --pic-executable Create a position independent executable --sort-common [=ascending|descending] Sort common symbols by alignment [in specified order] --sort-section name|alignment Sort sections by name or maximum alignment --spare-dynamic-tags ANTAL Hvor mange m�rker som skal reserveres i .dynamic-sektion --split-by-file [=ST�RRELSE] Del uddatasektioner hver ST�RRELSE oktetter --split-by-reloc [=ANTAL] Del uddatasektioner hver ANTAL relokeringer --stats Vis statistik over hukommelsesbrug --target-help Vis m�lspecifikke flag --task-link SYMBOL Udf�r l�nkning p� opgaveniveau --traditional-format Brug samme format som indbygget l�nker --section-start SEKTION=ADRESSE S�t adresse p� navngiven sektion -Tbss ADRESSE S�t adresse p� .bss-sektion -Tdata ADRESSE S�t adresse p� .data-sektion -Ttext ADRESSE S�t adresse p� .text-sektion -Ttext-segment ADRESSE S�t adresse p� .text-segment -Trodata-segment ADRESSE Set address of rodata segment -Tldata-segment ADRESSE Set address of ldata segment --unresolved-symbols=<method> How to handle unresolved symbols. <method> is: ignore-all, report-all, ignore-in-object-files, ignore-in-shared-libs --verbose [=NUMBER] Vis meget information under l�nkning --version-script FIL L�s skript med versionsinformation --version-exports-section SYMBOL Tag liste med eksportsymboler fra .exports og brug SYMBOL som version. --dynamic-list-data Add data symbols to dynamic list --dynamic-list-cpp-new Use C++ operator new/delete dynamic list --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list --dynamic-list FIL Read dynamic list --export-dynamic-symbol SYMBOL Export the specified symbol --export-dynamic-symbol-list FIL Read export dynamic symbol list --warn-common Advar for duplerede f�lles symboler --warn-constructors Advar hvis globale konstruktorer/destruktorer findes --warn-multiple-gp Advar hvis flere GP-v�rdier bruges --warn-once Advar kun �n gang per udefineret symbol --warn-section-align Advar hvis begyndelsen p� sektionen �ndres p� grund af justering --warn-textrel Warn if outpout has DT_TEXTREL --warn-alternate-em Warn if an object has alternate ELF machine code --warn-unresolved-symbols Report unresolved symbols as warnings --error-unresolved-symbols Report unresolved symbols as errors --whole-archive Inklud�r alle objekter fra f�lgende arkiver --wrap SYMBOL Brug indkapslingsfunktioner for SYMBOL --ignore-unresolved-symbol SYMBOL Unresolved SYMBOL will not cause an error or warning --push-state Push state of flags governing input file handling --pop-state Pop state of flags governing input file handling --print-memory-usage Report target memory usage --orphan-handling =MODE Control how orphan sections are handled. --print-map-discarded Show discarded sections in map file output (default) --no-print-map-discarded Do not show discarded sections in map file output @FIL Read options from FILE C:\Msys64\mingw64\bin\ld.exe: m�l som underst�ttes: pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 elf64-l1om elf64-k1om pe-i386 pei-i386 elf32-i386 elf32-iamcu elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin C:\Msys64\mingw64\bin\ld.exe: emuleringer som underst�ttes: i386pep i386pe C:\Msys64\mingw64\bin\ld.exe: emuleringsspecifikke flag: i386pep: --base_file <basefil> Gener�r en basefil for relok�rbare DLL'er --dll S�t billedbase til standard for DLL'er --file-alignment <st�rrelse> S�t filjustering --heap <st�rrelse> S�t initiel st�rrelse p� bunken --image-base <adresse> S�t startadressen for den k�rbare --major-image-version <nummer> S�t versionsnummer for den k�rbare --major-os-version <nummer> S�t laveste kr�vet OS-version --major-subsystem-version <nummer> S�t laveste n�dvendige OS-undersystemsversion --minor-image-version <nummer> S�t underrevisionsnummer for den k�rbare --minor-os-version <nummer> S�t laveste kr�vet OS-revision --minor-subsystem-version <nummer> S�t laveste n�dvendige OS-undersystemsrevision --section-alignment <st�rrelse> S�t sektionsjustering --stack <st�rrelse> S�t st�rrelse p� initiel stak --subsystem <navn>[:<version>] S�t n�dvendigt OS-undersystem [og kr�vet version] --support-old-code Underst�ttelse samvirken med gammel kode --[no-]leading-underscore Set explicit symbol underscore prefix mode --[no-]insert-timestamp Use a real timestamp rather than zero (default) This makes binaries non-deterministic --add-stdcall-alias Eksport�r symboler med og uden @nn --disable-stdcall-fixup L�nk ikke _sym til _sym@nn --enable-stdcall-fixup L�nk _sym til _sym@nn uden advarsler --exclude-symbols sym,sym,... Udelad symboler fra automatisk eksport --exclude-all-symbols Udelad alle symboler fra automatisk eksport --exclude-libs bibl,bibl,... Udelad bibliotek fra automatisk export --exclude-modules-for-implib mod,mod,... Exclude objects, archive members from auto export, place into import library instead --export-all-symbols Eksport�r automatisk alle symboler til DLL --kill-at Fjern @nn fra eksporterede symboler --output-def <fil> Gener�r en .DEF-fil for bygget DLL --warn-duplicate-exports Warn about duplicate exports --compat-implib Create backward compatible import libs; create __imp_<SYMBOL> as well --enable-auto-image-base V�lg automatisk billedbase for DLL'er med mindre brugeren ikke angiver �n <- here --disable-auto-image-base Do not auto-choose image base (default) --dll-search-prefix=<streng> Brug <streng><basenavn>.dll i stedet for lib<basenavn>.dll ved dynamisk l�nkning uden et importbibliotek --enable-auto-import Do sophisticated linking of _sym to __imp_sym for DATA references --disable-auto-import Import�r ikke DATA-objekter fra DLL'er automatisk --enable-runtime-pseudo-reloc Work around auto-import limitations by adding pseudo-relocations resolved at runtime <- here --disable-runtime-pseudo-reloc Do not add runtime pseudo-relocations for auto-imported DATA --enable-extra-pep-debug Enable verbose debug output when building or linking to DLLs (esp. auto-import) --enable-long-section-names Use long COFF section names even in executable image files --disable-long-section-names Never use long COFF section names, even in object files --[disable-]high-entropy-va Image is compatible with 64-bit address space layout randomization (ASLR) --[disable-]dynamicbase Image base address may be relocated using address space layout randomization (ASLR) --enable-reloc-section Create the base relocation table --disable-reloc-section Do not create the base relocation table --[disable-]forceinteg Code integrity checks are enforced --[disable-]nxcompat Image is compatible with data execution prevention --[disable-]no-isolation Image understands isolation but do not isolate the image --[disable-]no-seh Image does not use SEH; no SE handler may be called in this image --[disable-]no-bind Do not bind this image --[disable-]wdmdriver Driver uses the WDM model --[disable-]tsaware Image is Terminal Server aware --build-id[=STYLE] Generate build ID --default-image-base-low Default image bases under 4GB --default-image-base-high Default image bases over 4GB i386pe: --base_file <basefil> Gener�r en basefil for relok�rbare DLL'er --dll S�t billedbase til standard for DLL'er --file-alignment <st�rrelse> S�t filjustering --heap <st�rrelse> S�t initiel st�rrelse p� bunken --image-base <adresse> S�t startadressen for den k�rbare --major-image-version <nummer> S�t versionsnummer for den k�rbare --major-os-version <nummer> S�t laveste kr�vet OS-version --major-subsystem-version <nummer> S�t laveste n�dvendige OS-undersystemsversion --minor-image-version <nummer> S�t underrevisionsnummer for den k�rbare --minor-os-version <nummer> S�t laveste kr�vet OS-revision --minor-subsystem-version <nummer> S�t laveste n�dvendige OS-undersystemsrevision --section-alignment <st�rrelse> S�t sektionsjustering --stack <st�rrelse> S�t st�rrelse p� initiel stak --subsystem <navn>[:<version>] S�t n�dvendigt OS-undersystem [og kr�vet version] --support-old-code Underst�ttelse samvirken med gammel kode --[no-]leading-underscore Set explicit symbol underscore prefix mode --thumb-entry=<symbol> S�t indgangspunktet til at v�re tommel <symbol> --[no-]insert-timestamp Use a real timestamp rather than zero (default). This makes binaries non-deterministic --add-stdcall-alias Eksport�r symboler med og uden @nn --disable-stdcall-fixup L�nk ikke _sym til _sym@nn --enable-stdcall-fixup L�nk _sym til _sym@nn uden advarsler --exclude-symbols sym,sym,... Udelad symboler fra automatisk eksport --exclude-all-symbols Udelad alle symboler fra automatisk eksport --exclude-libs bibl,bibl,... Udelad bibliotek fra automatisk export --exclude-modules-for-implib mod,mod,... Exclude objects, archive members from auto export, place into import library instead. --export-all-symbols Eksport�r automatisk alle symboler til DLL --kill-at Fjern @nn fra eksporterede symboler --output-def <fil> Gener�r en .DEF-fil for bygget DLL --warn-duplicate-exports Warn about duplicate exports --compat-implib Opret bagudkompatible importbiblioteker; og opret ogs� __imp_<SYMBOL>. --enable-auto-image-base[=<address>] Automatically choose image base for DLLs (optionally starting with address) unless specifically set with --image-base <- and here --disable-auto-image-base V�lg ikke billedbase automatisk (standard). --dll-search-prefix=<streng> Brug <streng><basenavn>.dll i stedet for lib<basenavn>.dll ved dynamisk l�nkning uden et importbibliotek --enable-auto-import Do sophisticated linking of _sym to __imp_sym for DATA references --disable-auto-import Import�r ikke DATA-objekter fra DLL'er automatisk --enable-runtime-pseudo-reloc Work around auto-import limitations by adding pseudo-relocations resolved at runtime. <- here to --disable-runtime-pseudo-reloc Do not add runtime pseudo-relocations for auto-imported DATA. --enable-extra-pe-debug Brug udf�rlig fejls�gningsuddata ved bygning af eller l�nkning til DLL'er (is�r automatisk import) --large-address-aware Executable supports virtual addresses greater than 2 gigabytes --disable-large-address-aware Executable does not support virtual addresses greater than 2 gigabytes --enable-long-section-names Use long COFF section names even in executable image files --disable-long-section-names Never use long COFF section names, even in object files --[disable-]dynamicbase Image base address may be relocated using address space layout randomization (ASLR) --enable-reloc-section Create the base relocation table --disable-reloc-section Do not create the base relocation table --[disable-]forceinteg Code integrity checks are enforced --[disable-]nxcompat Image is compatible with data execution prevention --[disable-]no-isolation Image understands isolation but do not isolate the image --[disable-]no-seh Image does not use SEH. No SE handler may be called in this image --[disable-]no-bind Do not bind this image --[disable-]wdmdriver Driver uses the WDM model --[disable-]tsaware Image is Terminal Server aware --build-id[=STYLE] Generate build ID

not sure if a bug but the list gets rather confusing with multiple options to runtime-pseudo-relocs and others all over the place.

[revelator]

...doh i forgot the 64 bit binutils supports both targets forget the above.
on another note instead of using LDFLAGS_FOR_TARGET use BOOT_LDFLAGS to get it to pass the aslr flags to stage2 and 3.
sadly while this gets pretty far it still croaks on --dynamicbase in stage2. I also noticed that gcc turns of position independant for some tools like genmddeps but it uses the -no-PIE flag instead of ld's --disable-dynamicbase. on linux -PIE and -fpie is needed for aslr but these flags seem to break on windows.