COFF support for Win32 #3843

rainers · 2014-08-02T15:28:58Z

As this comes up in the NG now and then, these are the compiler patches to build COFF files for Win32.

use command line option -m32coff
it defines versions CRuntime_DigitalMars and CRuntime_Microsoft (and CRuntime_GNU) as it is no longer possible to detect the C runtime from the OS. This can also replace all the similar adhoc versionings in druntime/phobos.
C++ interfacing isn't adjusted yet, the rest of the test suite seems to succeed

The corresponding druntime and phobos changes are here (mostly dealing with the CRuntime versions):

https://github.com/rainers/druntime/tree/coff32
https://github.com/rainers/phobos/tree/coff32

If there is a chance of this getting merged, I can make them pull requests, too.

Trass3r · 2014-08-02T15:46:50Z

@redstar What do you think about the version names?

ghost · 2014-08-03T16:43:23Z

I'd label this with "New Feature" and "Big Pull/Major Changes", but I can't seem to add new labels.

yebblies · 2014-08-03T17:04:34Z

src/mars.c

@@ -40,7 +40,11 @@
 #include "doc.h"
 #include "color.h"

+#include "backend/cdef.h"


This header shouldn't be leaking into the frontend. I think the usual way is to make our own types and translate in glue/backconfig?

I remember having been in #include hell regarding cdef.h before (https://github.com/D-Programming-Language/dmd/pull/3542/files). I guess introducing the output format in the options of the frontend won't fly with Walter, too. I'll convert it to an "bool coff;" there.

I don't mind having the output format in the frontend, but any backend headers will need to be special-cased in ddmd.

yebblies · 2014-08-03T17:09:06Z

I think this is definitely worth doing. I think the first step is to get the CRuntime_* versions in, preferably matching the existing identifiers that I assume gdc/ldc have.

Trass3r · 2014-08-03T21:45:46Z

Ldc's used DMC_RUNTIME vs. MSVC_RUNTIME so far.

redstar · 2014-08-04T04:41:03Z

I think the version names are ok. I like to see standard names instead of the ad hock ones spread around druntime/phobos.

ibuclaw · 2014-08-04T06:08:24Z

I'm not a fan of the names. What would the difference be between CRuntime_GNU and MinGW? I'm assuming none.

rainers · 2014-08-04T07:17:49Z

Ldc's used DMC_RUNTIME vs. MSVC_RUNTIME so far.

All uppercase has little precedence in existing version identifiers.

rainers · 2014-08-04T07:21:51Z

I'm not a fan of the names. What would the difference be between CRuntime_GNU and MinGW? I'm assuming none.

CRuntime_GNU is currently just meant as a place holder for anything else but DigitalMars and Microsoft. I expect there should be Posix, Bionic and others.

WalterBright · 2014-08-06T09:16:45Z

I've been referring to coff in the source code as "mscoff", not "coff", as it really is not the usual coff format. Microsoft has diverged it substantially. I'd prefer the name mscoff was used instead.

rainers · 2014-08-12T07:17:11Z

I've been referring to coff in the source code as "mscoff", not "coff", as it really is not the usual coff format. Microsoft has diverged it substantially. I'd prefer the name mscoff was used instead.

I have renamed everything from "coff" to "mscoff".

WalterBright · 2014-08-15T01:34:32Z

src/backend/backconfig.c

@@ -64,6 +64,8 @@ void out_config_init(
    config.memmodel = 0;
    config.flags |= CFGuchar;   // make sure TYchar is unsigned
    tytab[TYchar] |= TYFLuns;
+    bool mscoff = model & 1;
+    model &= ~0x1f;


Replace with:

model &= 64 | 32;

and add the 1 bit to the documentation of model parameter

Will do.

I think this is the ugliest part of this PR. I always wondered why the backend configuration is not a struct declared in a header file. Right now, the prototype for out_config_init is duplicated in msc.c making it inconvenient to add another option because other backends will need to be updated, too.

COFF support for Win32

rainers · 2014-08-17T20:26:02Z

Thanks for merging. Actually, I expected more discussion regarding the CRuntime version identifiers...

WalterBright · 2014-08-18T01:57:17Z

I'm not up for more bikeshedding about internal identifier names :-)

yebblies · 2014-08-18T04:47:48Z

Thanks for merging. Actually, I expected more discussion regarding the CRuntime version identifiers...

So was I, but we have up until the next release to settle on something with GDC and LDC.

ibuclaw · 2014-08-20T09:10:29Z

Nothing actually touches shared code (except mars.h) so I'd be inclined to ignore that the identifier even exists.

The only time I'd start raising eyebrows is if you decide to actually use it in druntime/phobos.

yebblies · 2014-08-20T09:13:28Z

It may not actually be shared code, but I assume you're going to mirror the addPredefinedGlobalIdent changes, right? And of course they'll be used in druntime/phobos.

ibuclaw · 2014-08-20T13:04:56Z

@yebblies it makes no sense to anything other than CRuntime_GNU - but this is no different than plain old GNU.

ibuclaw · 2014-08-20T13:07:19Z

Or at least, I can't immediately see what the meaning of these are. For instance, would Bionic still be CRuntime_GNU?

ibuclaw · 2014-08-20T13:08:15Z

What about OSX, which uses Clang?

ibuclaw · 2014-08-20T13:11:02Z

What about MinGW? Are the library changes going to break support for that / cause more sporking of the D library? (I would have thought the answer be yes)/

WalterBright · 2014-08-20T18:17:51Z

Clang and gcc on OSX, as far as I can tell, are compatible enough that there's no need for D to distinguish between them.

If there's impetus for MinGW on Windows, then it'll need another identifier for that one.

ibuclaw · 2014-08-21T07:52:19Z

GDC only supports MinGW, and there are (alpha/untested) binaries available. I don't think it needs a new identifier, it already has a suitably named one - version(MinGW)

rainers · 2014-08-22T07:15:25Z

According to the spec, version GNU is defined by the compiler GDC, it is not explicite about the target C-runtime that the executable is going to be linked with. In cmbination with the OS this is only a problem if there are multiple C libraries that might get used on the same platform. With using the prefix "CRuntime_" I wanted to make that more explicite.

MinGW and Cygwin are version identifiers probably meant for the same purpose, though the description "The MinGW environment" doesn't make that very clear. Taking these as precedence for other runtimes, "DigitalMars" and "Microsoft" would be natural choices, but "DigitalMars" is already used for the compiler.

If CRuntime_GNU just makes things more ambiguous I'm in favor of removing it. The current patches only use CRuntime_DigitalMars and CRuntime_Microsoft to make the distinction for the Windows platform.

ibuclaw · 2014-08-22T08:20:38Z

Well, the only runtimes I can list support (or potential) for are:

mingw
cygwin
freebsd
glibc
uclibc
bionic

And the only pair that has come up recently (Linux glibc/bionic) I was never much in favour of meshing the two together in the same file anyway, but that's what you seem to be doing here with Windows.

version(Win32)
{
    version(DMC)
    /* ... */
    else version(Microsoft)
    /* ... */
    else version(MinGW)
    /* ... */
    else version(Cygwin)
    /* ... */
}
else version(Win64)
{
    /* repeat */
}

rainers · 2014-08-23T07:35:58Z

The API differences between Win32 and Win64 are usually smaller than the differences between C runtimes (DMC vs. Microsoft). So I don't think it is sensible to distinguish between 32-bit and 64-bit at the top-most level.
I am not convinced one fixed hierarchy for OS, processor, architecture, C-Runtime etc. is maintainable, because they are interleaved in non-orthogonal ways. It's a judgement call for each and every API subsystem.

rainers · 2014-08-23T07:40:35Z

Well, the only runtimes I can list support (or potential) for are:
mingw, cygwin, freebsd, glibc, uclibc, bionic

Wouldn't it be better to make it clear in the version identifier that the C runtimes are meant, not the build environment (though that is usually coupled to some extent)?

ibuclaw · 2014-08-26T12:26:49Z

The API differences between Win32 and Win64 are usually smaller than the differences between C runtimes (DMC vs. Microsoft). So I don't think it is sensible to distinguish between 32-bit and 64-bit at the top-most level.

Maybe give DMD a DigitalMars_* vendor-specific version then? Only DMD will ever use dmc runtime. version(Windows) could then assume to be always Microsoft.

I'm only suggesting as it is nothing short of 'rather odd' to have an identifier for runtimes. Not even C compilers go to the bother of doing that.

ibuclaw · 2014-08-26T12:30:29Z

As for MinGW, there's only a couple of places that I know of where it deviates from Microsoft signatures (ignoring ABI compat). Maybe things should be fixed up there so we're not piggy backing off the fact that most of the Win64/Win32 declarations in druntime match that in MinGW runtime.

rainers · 2014-08-27T06:36:47Z

I'm only suggesting as it is nothing short of 'rather odd' to have an identifier for runtimes. Not even C compilers go to the bother of doing that.

You might be right that the runtime is very much coupled to the compiler, so instead of CRuntime_... we could use an identifier that specifies the C compiler that is used to build C files we are linking to. That fits slightly better when using functions expected to exist by the compiler, like _alldiv for the long integer mul/div operations.

But we don't have an explicite identifier for that yet. It might be best to match what compiler vendors are using themselves. Here is a list of compiler identifiers: http://sourceforge.net/p/predef/wiki/Compilers/

For Windows, this suggests using __DMC__ and _MSC_VER_, maybe omitting underscores or adding some prefix, say "CC_DMC" and "CC_MSC".

ibuclaw · 2014-08-27T10:13:35Z

There is a rather distinct difference between coupled compiler/compiler runtime and C (std) runtime.

The latter has no coupling at all.

rainers · 2014-08-27T20:06:18Z

There is a rather distinct difference between coupled compiler/compiler runtime and C (std) runtime.
The latter has no coupling at all.

I cannot tell about linux/mac, but on windows, they are coupled by being in the same library (e.g. snn.lib or libcmt.lib).
I'm not sure if you are now proposing that compiler and C runtime are uncoupled, so the latter cannot be identified by the existing version identifiers?

ibuclaw · 2014-08-28T06:34:07Z

I'm not sure if you are now proposing that compiler and C runtime are uncoupled,

I'm not proposing. I'm just saying what has (or should) always been the case.

so the latter cannot be identified by the existing version identifiers?

There is no standard macro in C.

There are vendor macros in GDC though - GNU_GLibc, GNU_UCLibc and GNU_Bionic. You are free to use these if you absolutely must, but I'd rather druntime stay clean of them as it opens a can of worms for maintenance - eg: 45 version code paths just for Linux (x86/GLibc, x86_64/GLibc, ARM/GLibc, ...). I had proposed it once before to have a /ports directory with Bionic bindings for core.stdc - this didn't happen though.

Remove `lifetime_init`

COFF support for Win32, use command line option -m32coff

af4e0a5

yebblies reviewed Aug 3, 2014
View reviewed changes

ghost added the Enhancement label Aug 4, 2014

use bool "coff" instead of objfmt in the frontend

a9d39f9

use "mscoff" instead of "coff"

23f1fc0

WalterBright reviewed Aug 15, 2014
View reviewed changes

document COFF bit in model value

2a5b0a8

WalterBright added a commit that referenced this pull request Aug 17, 2014

Merge pull request #3843 from rainers/coff32

a7a3c78

COFF support for Win32

WalterBright merged commit a7a3c78 into dlang:master Aug 17, 2014

rainers mentioned this pull request Aug 23, 2014

replace stray tabs with spaces #3890

Merged

Jebbs mentioned this pull request Dec 17, 2014

Can DSFML be built as a collection of shared libraries? Jebbs/DSFML#135

Open

ibuclaw pushed a commit to ibuclaw/dmd that referenced this pull request Jul 10, 2022

Merge pull request dlang#3843 from dkorpel/remove-lifetime-init

8f12ffe

Remove `lifetime_init`

COFF support for Win32 #3843

COFF support for Win32 #3843

Conversation

rainers commented Aug 2, 2014

Trass3r commented Aug 2, 2014

ghost commented Aug 3, 2014

yebblies Aug 3, 2014

Choose a reason for hiding this comment

rainers Aug 4, 2014

Choose a reason for hiding this comment

yebblies Aug 4, 2014

Choose a reason for hiding this comment

yebblies commented Aug 3, 2014

Trass3r commented Aug 3, 2014

redstar commented Aug 4, 2014

ibuclaw commented Aug 4, 2014

rainers commented Aug 4, 2014

rainers commented Aug 4, 2014

WalterBright commented Aug 6, 2014

rainers commented Aug 12, 2014

WalterBright Aug 15, 2014

Choose a reason for hiding this comment

rainers Aug 16, 2014

Choose a reason for hiding this comment

rainers commented Aug 17, 2014

WalterBright commented Aug 18, 2014

yebblies commented Aug 18, 2014

ibuclaw commented Aug 20, 2014

yebblies commented Aug 20, 2014

ibuclaw commented Aug 20, 2014

ibuclaw commented Aug 20, 2014

ibuclaw commented Aug 20, 2014

ibuclaw commented Aug 20, 2014

WalterBright commented Aug 20, 2014

ibuclaw commented Aug 21, 2014

rainers commented Aug 22, 2014

ibuclaw commented Aug 22, 2014

rainers commented Aug 23, 2014

rainers commented Aug 23, 2014

ibuclaw commented Aug 26, 2014

ibuclaw commented Aug 26, 2014

rainers commented Aug 27, 2014

ibuclaw commented Aug 27, 2014

rainers commented Aug 27, 2014

ibuclaw commented Aug 28, 2014