On 3/3/2012 12:44 PM, Daniel Murphy wrote:
"Bernard Helyer"<[email protected]> wrote in message
news:[email protected]...
No one thinks that's a bad idea. The trouble is the amount of developers
that actually understand the backend enough to implement another object
format (which is what's needed to support the VisualC linker) is very
small.
What's needed is someone to take the time to learn it then do it. Someone
motivated, and smart. Not unlike yourself! :P
The problem isn't really the backend - there are currently _three_ full
object file generators in dmd and it should be possible to use the same
interfaces these do without caring what most of the backend is really doing.
A good step forward would be a better separation of the object file
format from the target OS and the host OS. Removing that preprocessor
hell is needed anyway if you want to switch between object file formats
by a command line switch.
In addition, it would be pretty nice if you could at least compile with
predefined version OSX, even if you are working on Windows.
Generating Microsoft coff objects means deciphering the spec to see what
everything should look like, generating every kind of entry with msvc to see
what it _actually_ does, then translating all the record/fixup/section types
from omf to the coff equivalents. With this (and maybe updates to the
runtime to use msvc's instead of dmc's c runtime) you have 32 bit coff on
windows.
Don't forget debug info: as far as I can tell, the Microsoft linker
accepts codeview debug info in the object file, you don't have to write
pdb files. From my experience with cv2pdb, the debug records are a
straight forward extension of the debug info currently written by dmd.
