www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - bugzilla 424 - Unexpected OPTLINK Termination - solved!

reply Walter Bright <newshound1 digitalmars.com> writes:
Optlink is written entirely in rather impenetrable assembler code, and 
is resistant to understanding and modification. Hence, over the last few 
months I've been very slowly converting it to C, function by function.

One might ask, why not convert it to D? The answer is that I don't have 
a good test suite for optlink, so I have to be very very careful to not 
make a mistake in the translation. That means do one function at a time, 
rebuild, and retest, which means the compiled C code has to match the 
segment, naming and calling conventions used in optlink. I made a custom 
version of the dmc compiler to do this. Also, C can be made to work 
without any runtime library support at all, and since optlink does not 
use the C runtime library, this is useful.

Once it is in C and working, it will be trivial to translate it to D and 
start rewriting it.

Anyhow, during this process I stumbled upon what the problem was. 
Optlink was apparently trying to account for some Borland obscure 
extension to the OMF. Remove this, and it works, although presumably it 
will no longer link Borland object files (who cares!).

The fix will go out in the next update, if you need it sooner please 
email me.
Nov 03 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
This is the too many fixups bug?!
If so that's great news.

So is it any slower now with things not in ASM?

--bb

On Tue, Nov 3, 2009 at 10:39 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Optlink is written entirely in rather impenetrable assembler code, and is
 resistant to understanding and modification. Hence, over the last few months
 I've been very slowly converting it to C, function by function.

 One might ask, why not convert it to D? The answer is that I don't have a
 good test suite for optlink, so I have to be very very careful to not make a
 mistake in the translation. That means do one function at a time, rebuild,
 and retest, which means the compiled C code has to match the segment, naming
 and calling conventions used in optlink. I made a custom version of the dmc
 compiler to do this. Also, C can be made to work without any runtime library
 support at all, and since optlink does not use the C runtime library, this
 is useful.

 Once it is in C and working, it will be trivial to translate it to D and
 start rewriting it.

 Anyhow, during this process I stumbled upon what the problem was. Optlink
 was apparently trying to account for some Borland obscure extension to the
 OMF. Remove this, and it works, although presumably it will no longer link
 Borland object files (who cares!).

 The fix will go out in the next update, if you need it sooner please email
 me.

Nov 03 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 This is the too many fixups bug?!
 If so that's great news.

Yah. http://d.puremagic.com/issues/show_bug.cgi?id=424 Andrei
Nov 03 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 So is it any slower now with things not in ASM?

Haven't measured it, but I doubt it, as it's only about 5% in C now. Although asm code can be very small and fast, and optlink is the best of the best at that, it tends to be brittle (very hard to change the algorithm). The biggest speed gains are from algorithmic improvements.
Nov 03 2009
prev sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Bill Baxter wrote:
 
 So is it any slower now with things not in ASM?
 
 --bb
 

You are not serious are you? The linker not the linked? If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?
Nov 04 2009
parent Franklin Minty <franmin gmail.com> writes:
Tim Matthews Wrote:

 Bill Baxter wrote:
 
 So is it any slower now with things not in ASM?
 
 --bb
 

You are not serious are you? The linker not the linked? If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?

it will be slower - I want my 100ms back.
Nov 04 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hcptci$l06$1 digitalmars.com...
 [great optlink news]

That's great news!
Nov 03 2009
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Am I dreaming? This is too good to be true :O Walter, have you been 
replaced by an alien or reprogrammed using some sci-fi device? I can't 
believe the MsgBox of death is going away!


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
Nov 03 2009
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Walter Bright Wrote:

 Optlink is written entirely in rather impenetrable assembler code, and 
 is resistant to understanding and modification. Hence, over the last few 
 months I've been very slowly converting it to C, function by function.
 
 One might ask, why not convert it to D? The answer is that I don't have 
 a good test suite for optlink, so I have to be very very careful to not 
 make a mistake in the translation. That means do one function at a time, 
 rebuild, and retest, which means the compiled C code has to match the 
 segment, naming and calling conventions used in optlink. I made a custom 
 version of the dmc compiler to do this. Also, C can be made to work 
 without any runtime library support at all, and since optlink does not 
 use the C runtime library, this is useful.
 
 Once it is in C and working, it will be trivial to translate it to D and 
 start rewriting it.
 
 Anyhow, during this process I stumbled upon what the problem was. 
 Optlink was apparently trying to account for some Borland obscure 
 extension to the OMF. Remove this, and it works, although presumably it 
 will no longer link Borland object files (who cares!).
 
 The fix will go out in the next update, if you need it sooner please 
 email me.

Why not changing object format instead and using format acceptable by the linker from MinGW suit? That could free you from rewriting the linker in C, then in D and then maintaining it. Are there any difficulties (technical or even licensing)?
Nov 03 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Eldar Insafutdinov wrote:
 Why not changing object format instead and using format acceptable by
 the linker from MinGW suit? That could free you from rewriting the
 linker in C, then in D and then maintaining it. Are there any
 difficulties (technical or even licensing)?

I'd have to give up the entire toolchain on windows to do that. Also, the gnu linker is dog slow.
Nov 03 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Walter Bright Wrote:

 Eldar Insafutdinov wrote:
 Why not changing object format instead and using format acceptable by
 the linker from MinGW suit? That could free you from rewriting the
 linker in C, then in D and then maintaining it. Are there any
 difficulties (technical or even licensing)?

I'd have to give up the entire toolchain on windows to do that. Also, the gnu linker is dog slow.

Ok, thank you for the answer and for fixing optlink!
Nov 03 2009
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 03/11/2009 20:39, Walter Bright wrote:
 Optlink is written entirely in rather impenetrable assembler code, and
 is resistant to understanding and modification. Hence, over the last few
 months I've been very slowly converting it to C, function by function.

 One might ask, why not convert it to D? The answer is that I don't have
 a good test suite for optlink, so I have to be very very careful to not
 make a mistake in the translation. That means do one function at a time,
 rebuild, and retest, which means the compiled C code has to match the
 segment, naming and calling conventions used in optlink. I made a custom
 version of the dmc compiler to do this. Also, C can be made to work
 without any runtime library support at all, and since optlink does not
 use the C runtime library, this is useful.

 Once it is in C and working, it will be trivial to translate it to D and
 start rewriting it.

 Anyhow, during this process I stumbled upon what the problem was.
 Optlink was apparently trying to account for some Borland obscure
 extension to the OMF. Remove this, and it works, although presumably it
 will no longer link Borland object files (who cares!).

 The fix will go out in the next update, if you need it sooner please
 email me.

awesome news! Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.
Nov 03 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Yigal Chripun wrote:
 Once Optlink is moved to C and than D, it could grow new 
 features like link-time optimizations.

It does open up a lot of possibilities. One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat. Currently, COMDATs are merged if and only if their names match exactly. Another possibility is to merge the linker with dmd, so it can generate executables directly without having to go through an object file step.
Nov 03 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Yigal Chripun wrote:
 Once Optlink is moved to C and than D, it could grow new features like 
 link-time optimizations.

It does open up a lot of possibilities. One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat. Currently, COMDATs are merged if and only if their names match exactly. Another possibility is to merge the linker with dmd, so it can generate executables directly without having to go through an object file step.

Well it opens up a lot of possibilities *on Windows only*, which is liable to dampen some enthusiasm. Andrei
Nov 03 2009
prev sibling next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
On 04/11/2009 00:18, Walter Bright wrote:
 Yigal Chripun wrote:
 Once Optlink is moved to C and than D, it could grow new features like
 link-time optimizations.

It does open up a lot of possibilities. One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat. Currently, COMDATs are merged if and only if their names match exactly. Another possibility is to merge the linker with dmd, so it can generate executables directly without having to go through an object file step.

Merging the linker with DMD is an excellent idea. There still should be a flag to generate object files, but in general there are only two useful artifacts the compiler should generate: executable and lib. I'd want to see also integration of DDL or something similar in concept so the libs generated by DMD could be used as shared libs. Another feature that would be nice to have is incremental compilation. each time you run dmd it would update the previous lib file with the delta of changes instead of regenerating it from scratch.
Nov 03 2009
prev sibling parent BLS <windevguy hotmail.de> writes:
On 03/11/2009 23:18, Walter Bright wrote:
 Yigal Chripun wrote:
 Once Optlink is moved to C and than D, it could grow new features like
 link-time optimizations.

It does open up a lot of possibilities. One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat.

I think this could give DWT the necessary new breath...
Nov 04 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 Anyhow, during this process I stumbled upon what the problem was. 
 Optlink was apparently trying to account for some Borland obscure 
 extension to the OMF. Remove this, and it works, although presumably it 
 will no longer link Borland object files (who cares!).

And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you). Additionally, I prefer a slow, working linker over a fast, crashing one.
Nov 04 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 4, 2009 at 10:21 AM, Leandro Lucarella <llucax gmail.com> wrote=
:
 grauzone, el =A04 de noviembre a las 17:23 me escribiste:
 Walter Bright wrote:
Anyhow, during this process I stumbled upon what the problem was.
Optlink was apparently trying to account for some Borland obscure
extension to the OMF. Remove this, and it works, although
presumably it will no longer link Borland object files (who
cares!).

And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.

And if you really find it slow, GNU Gold (done by Google) is *much* faster.

Interesting. Detailed series of 20 blog posts by the author here: http://www.airs.com/blog/archives/38 http://www.airs.com/blog/archives/39 ... http://www.airs.com/blog/archives/57 Looks like interesting reading. --bb
Nov 04 2009
prev sibling next sibling parent grauzone <none example.net> writes:
Leandro Lucarella wrote:
 grauzone, el  4 de noviembre a las 17:23 me escribiste:
 Walter Bright wrote:
 Anyhow, during this process I stumbled upon what the problem was.
 Optlink was apparently trying to account for some Borland obscure
 extension to the OMF. Remove this, and it works, although
 presumably it will no longer link Borland object files (who
 cares!).

without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.

And if you really find it slow, GNU Gold (done by Google) is *much* faster.

Last I heard from it, Gold (or dmd?) had some bugs which made it unusable with dmd. Did that get fixed meanwhile?
Nov 04 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 And during all that time, GNU ld worked just fine, completely without 
 bugs! I had to add hacks to my code to make it linkable on Windows.

I've spent many hours trying to find workarounds for ld problems and undocumented behaviors. The prime suspect in dmd not working on Snow Leopard is a change in the linker behavior.
 And no, GNU ld is not too slow. The most time during building is wasted 
 due to not having _working_ incremental building (Tom S discussed the 
 issues about that with you).

Do you mean incremental linking or incremental compiling?
 Additionally, I prefer a slow, working 
 linker over a fast, crashing one.

Of course. No argument there.
Nov 04 2009
parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 grauzone wrote:
 And during all that time, GNU ld worked just fine, completely without 
 bugs! I had to add hacks to my code to make it linkable on Windows.

I've spent many hours trying to find workarounds for ld problems and undocumented behaviors. The prime suspect in dmd not working on Snow Leopard is a change in the linker behavior.

I bet OPTLINK caused more work than ld for both you and your users in summary. Anyway, it's your software, your decisions etc...
 And no, GNU ld is not too slow. The most time during building is 
 wasted due to not having _working_ incremental building (Tom S 
 discussed the issues about that with you).

Do you mean incremental linking or incremental compiling?

Compiling. I think it had to do with emitting code for templates. DSSS (rebuild) had the same problem, and its author just gave up and called dmd once per source file, which made it awfully slow. xfbuild (Tom S is its author, isn't he?) incremental building still doesn't work for me because of the same issue.
 Additionally, I prefer a slow, working linker over a fast, crashing one.

Of course. No argument there.

Nov 04 2009
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
grauzone wrote:
 Walter Bright wrote:
 grauzone wrote:
 And no, GNU ld is not too slow. The most time during building is 
 wasted due to not having _working_ incremental building (Tom S 
 discussed the issues about that with you).

Do you mean incremental linking or incremental compiling?

Compiling. I think it had to do with emitting code for templates. DSSS (rebuild) had the same problem, and its author just gave up and called dmd once per source file, which made it awfully slow. xfbuild (Tom S is its author, isn't he?) incremental building still doesn't work for me because of the same issue.

The template emission method that DMD employs is a nice optimization, however until http://d.puremagic.com/issues/show_bug.cgi?id=3327 is fixed, incremental building may still be in trouble (and thus an option to control the emission might be useful). Additionally, http://d.puremagic.com/issues/show_bug.cgi?id=3328 is hindering the potential speed of an experimental incremental build tool I've created to work with the template emission optimization. The latter issue should be quite simple to to fix, but the former looks rather tricky and might be hitting some limitations of OMF. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 04 2009
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Nov 5, 09 02:21, Leandro Lucarella wrote:
 grauzone, el  4 de noviembre a las 17:23 me escribiste:
 Walter Bright wrote:
 Anyhow, during this process I stumbled upon what the problem was.
 Optlink was apparently trying to account for some Borland obscure
 extension to the OMF. Remove this, and it works, although
 presumably it will no longer link Borland object files (who
 cares!).

And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.

And if you really find it slow, GNU Gold (done by Google) is *much* faster.

Nov 04 2009
prev sibling parent =?iso-8859-15?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
Am 04.11.2009, 20:08 Uhr, schrieb Bill Baxter <wbaxter gmail.com>:

 Interesting.

 Detailed series of 20 blog posts by the author here:

 http://www.airs.com/blog/archives/38
 http://www.airs.com/blog/archives/39
 ...
 http://www.airs.com/blog/archives/57

 Looks like interesting reading.

Hi, wow. Great stuff. Saved and put into my knowledge-base archive. Robert
Nov 05 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 4, 2009 at 12:28 AM, Tim Matthews <tim.matthews7 gmail.com> wrote:
 Bill Baxter wrote:
 So is it any slower now with things not in ASM?

 --bb

You are not serious are you? The linker not the linked? If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?

Walter often defends sticking with OPTLINK because it is fast. And the implication is that it is fast in part because it's all in hand-coded ASM. I was merely curious if that was holding up or not, or if in fact being in ASM was irrelevant to the speed. I would think linkers would be mostly IO bound since they do fairly simple things with large amounts of data, so that would argue that it shouldn't matter much whether it's in ASM or C. --bb
Nov 04 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
grauzone, el  4 de noviembre a las 17:23 me escribiste:
 Walter Bright wrote:
Anyhow, during this process I stumbled upon what the problem was.
Optlink was apparently trying to account for some Borland obscure
extension to the OMF. Remove this, and it works, although
presumably it will no longer link Borland object files (who
cares!).

And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.

And if you really find it slow, GNU Gold (done by Google) is *much* faster. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Robar un alfajor es revolucionario, pues rompe con la idea de propiedad, incluso más que si se tratara de dinero. -- publikazion anarkista mdp (hablando de los destrozos de la Cumbre de las Americas en Mar del Plata, 2005)
Nov 04 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el  4 de noviembre a las 11:08 me escribiste:
 On Wed, Nov 4, 2009 at 10:21 AM, Leandro Lucarella <llucax gmail.com> wrote:
 grauzone, el  4 de noviembre a las 17:23 me escribiste:
 Walter Bright wrote:
Anyhow, during this process I stumbled upon what the problem was.
Optlink was apparently trying to account for some Borland obscure
extension to the OMF. Remove this, and it works, although
presumably it will no longer link Borland object files (who
cares!).

And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.

And if you really find it slow, GNU Gold (done by Google) is *much* faster.

Interesting. Detailed series of 20 blog posts by the author here:

BTW, Gold already support LTO (LInk Time Optimization) via plug-ins for both GCC (meaning GDC could use it in the future) and LLVM (meaning LDC could use it in the future, maybe even now, I didn't test it). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- CAYO HUGO CONZI --- TENIA PUESTA PELUCA -- Crónica TV
Nov 04 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
grauzone, el  4 de noviembre a las 20:23 me escribiste:
 Leandro Lucarella wrote:
grauzone, el  4 de noviembre a las 17:23 me escribiste:
Walter Bright wrote:
Anyhow, during this process I stumbled upon what the problem was.
Optlink was apparently trying to account for some Borland obscure
extension to the OMF. Remove this, and it works, although
presumably it will no longer link Borland object files (who
cares!).

without bugs! I had to add hacks to my code to make it linkable on Windows. And no, GNU ld is not too slow.

And if you really find it slow, GNU Gold (done by Google) is *much* faster.

Last I heard from it, Gold (or dmd?) had some bugs which made it unusable with dmd. Did that get fixed meanwhile?

Yes, I reported the bug[1] and it has been fixed in DMD 1.046 and 2.031. [1] http://d.puremagic.com/issues/show_bug.cgi?id=2932 -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- ... los cuales son susceptibles a una creciente variedad de ataques previsibles, tales como desbordamiento del tampón, falsificación de parámetros, ... -- Stealth - ISS LLC - Seguridad de IT
Nov 04 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 03 Nov 2009 10:39:13 -0800, Walter Bright wrote:

 Optlink is written entirely in rather impenetrable assembler code, and 
 is resistant to understanding and modification. Hence, over the last few 
 months I've been very slowly converting it to C, function by function.
 
 [...]
 
 Once it is in C and working, it will be trivial to translate it to D and 
 start rewriting it.
 
 Anyhow, during this process I stumbled upon what the problem was. 

That's definitely good news! Actually, I'm slowly working on a D linker myself. Writing it in D, from scratch. My goal is to allow linking a mix of OMF and COFF objects and libraries into the same executable, obviating the need for any conversion. I wonder if it's feasible to continue my work. I'm just a couple baby steps beyond the rough design stage. Well, probably I'll continue anyway, as long as I've got the courage. I like to re-invent wheels after all.
Nov 26 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sergey Gromov wrote:
 Actually, I'm slowly working on a D linker myself.  Writing it in D,
 from scratch.  My goal is to allow linking a mix of OMF and COFF objects
 and libraries into the same executable, obviating the need for any
 conversion.  I wonder if it's feasible to continue my work.  I'm just a
 couple baby steps beyond the rough design stage.
 
 Well, probably I'll continue anyway, as long as I've got the courage.  I
 like to re-invent wheels after all.

Building a linker itself is probably not too useful, given that it'll be hard to compete with optlink. What would be cool, though, is a linker that is able to do more advanced things - like organizing the code to minimize page loading, eliminating functions that are identical except for the name, etc.
Nov 26 2009
next sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Thu, 26 Nov 2009 12:02:59 -0800, Walter Bright wrote:

 Sergey Gromov wrote:
 Actually, I'm slowly working on a D linker myself.  Writing it in D,
 from scratch.  My goal is to allow linking a mix of OMF and COFF objects
 and libraries into the same executable, obviating the need for any
 conversion.  I wonder if it's feasible to continue my work.  I'm just a
 couple baby steps beyond the rough design stage.
 
 Well, probably I'll continue anyway, as long as I've got the courage.  I
 like to re-invent wheels after all.

Building a linker itself is probably not too useful, given that it'll be hard to compete with optlink. What would be cool, though, is a linker that is able to do more advanced things - like organizing the code to minimize page loading, eliminating functions that are identical except for the name, etc.

It's definitely possible to compete with optlink in maintainability and extensibility. :) As to the optimizations, we'll see if I can pull it off.
Nov 26 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 What would be cool, though, is a linker 
 that is able to do more advanced things -

This may be useful as guide (not used by LDC yet): http://llvm.org/docs/GoldPlugin.html Bye, bearophile
Nov 27 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Sergey Gromov wrote:
 Tue, 03 Nov 2009 10:39:13 -0800, Walter Bright wrote:
 
 Optlink is written entirely in rather impenetrable assembler code, and 
 is resistant to understanding and modification. Hence, over the last few 
 months I've been very slowly converting it to C, function by function.

 [...]

 Once it is in C and working, it will be trivial to translate it to D and 
 start rewriting it.

 Anyhow, during this process I stumbled upon what the problem was. 

That's definitely good news! Actually, I'm slowly working on a D linker myself. Writing it in D, from scratch. My goal is to allow linking a mix of OMF and COFF objects and libraries into the same executable, obviating the need for any conversion. I wonder if it's feasible to continue my work. I'm just a couple baby steps beyond the rough design stage. Well, probably I'll continue anyway, as long as I've got the courage. I like to re-invent wheels after all.

I hope you're making use of pragma's DDL code. He did so much work in making sense of the object file formats.
Nov 26 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 27 Nov 2009 01:10:36 +0100, Don wrote:

 Sergey Gromov wrote:
 Actually, I'm slowly working on a D linker myself.

I hope you're making use of pragma's DDL code. He did so much work in making sense of the object file formats.

Good thing you told me. I'll definitely try to reuse as much of DDL code as possible. Thanks for the pointer.
Nov 26 2009