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
next sibling 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 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 "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 reply 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
next sibling parent reply 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
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 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 reply 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!).


 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.


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
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!).


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.


 
 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 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.


But gold is ELF only, which is irrelevant for Windows.
Nov 04 2009
prev 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 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