Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
Bill Baxter, el 4 de noviembre a las 11:08 me escribiste: On Wed, Nov 4, 2009 at 10:21 AM, Leandro Lucarella llu...@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
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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?
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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...
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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 newshou...@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.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
Walter Bright newshou...@digitalmars.com wrote in message news:hcptci$l0...@digitalmars.com... [great optlink news] That's great news!
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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.
Re: bugzilla 424 - Unexpected OPTLINK Termination - solved!
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.
