I'm attempting to fix https://issues.dlang.org/show_bug.cgi?id=4831.  I've been debugging the optlink assembly and getting familiar with the code.  I have a couple questions though:

1. If I have any questions in the future about optlink who and where do I ask these questions? For now I'm posting to this forum because I'm not sure where else to send them.

2. Why are the assembly labels in this format: L<number>$?  I ask because I changed the labels for some functions so when I stepped through the assembly I had a better idea of what the code was doing.  So I'm not sure if I should leave the new labels or go back to the old L<number>$ labels.

3. Is there any documentation for developers who would like to contribute to optlink?  I'd like to make sure I'm following any style rules or guidelines.

Any information about developing for optlink would be helpful.  I haven't found much information online.  Thanks for any help, I'd like to start contributing to the D tools, its a crime to let all these bugs live on for so long when they are making adopting this language a hindrence for others.

On 7/29/2014 10:53 PM, Jonathan Marler wrote:
> I'm attempting to fix https://issues.dlang.org/show_bug.cgi?id=4831.  I've been
> debugging the optlink assembly and getting familiar with the code.  I have a
> couple questions though:
>
> 1. If I have any questions in the future about optlink who and where do I ask
> these questions? For now I'm posting to this forum because I'm not sure where
> else to send them.

I'm really the only person, except a couple others who have submitted PRs against optlink.


> 2. Why are the assembly labels in this format: L<number>$?  I ask because I
> changed the labels for some functions so when I stepped through the assembly I
> had a better idea of what the code was doing.  So I'm not sure if I should leave
> the new labels or go back to the old L<number>$ labels.

No known reason.


> 3. Is there any documentation for developers who would like to contribute to
> optlink?  I'd like to make sure I'm following any style rules or guidelines.

The fundamental problem with fixing optlink is there is essentially no test suite. This means that any fixes to it need to be surgical - as little code modified as practical, and pretty great care in doing it. Wholesale refactoring "just because" or for "cleanup" are out of the question. Wholesale reformatting is also out of the question.

Once what a function does is figured out, and its inputs and outputs identified, adding comments to that effect is appreciated. Most functions in Optlink do not identify what registers are used as input, what registers are used for output, and which registers must be preserved. Some functions even return results in flags. There is no consistency. To identify these, one must look at every call of that function.


> Any information about developing for optlink would be helpful.  I haven't found
> much information online.  Thanks for any help, I'd like to start contributing to
> the D tools, its a crime to let all these bugs live on for so long when they are
> making adopting this language a hindrence for others.

I appreciate you stepping up to make a difference on this.

What I've done to fix bugs in Optlink is to first identify where in the code things go wrong. Then, I convert that section of code to C. The C code, line by line, mirrors the assembler. Then I fix the C code. This makes things much easier because I can use printf, etc., in the C code.

Making dmd generate coff would make more sense.

On Wednesday, 30 July 2014 at 06:54:52 UTC, Walter Bright wrote:
> The fundamental problem with fixing optlink is there is essentially no test suite. This means that any fixes to it need to be surgical - as little code modified as practical, and pretty great care in doing it. Wholesale refactoring "just because" or for "cleanup" are out of the question. Wholesale reformatting is also out of the question.

The solution there is to write a comprehensive test suite. Then it can be refactored. I'm not saying it's an easy solution, it's probably a major pain, but that's what it is.

On 30/07/2014 7:03 p.m., Kagamin wrote:
> Making dmd generate coff would make more sense.
+1
Most of the code should already be present in dmd, which makes it far crazier not to.

It looks like the easiest way to fix the bug is to change the get_filename function to support non HPFS characters.  I'm guessing this was originally written to run exclusively on HPFS systems?  Is this tool still suppose to support HPFS file systems?  If so maybe we could add a runtime check to see what kind of fs the program is being run on (or a compile time check if we are guaranteed that each system with a different file system will use a different build, I'm guessing this is not the case.)  If HPFS does not need to be supported then the fix is really easy.

I also found a buffer overrun bug in the get_filename function (if your filename does not have an ending quote).

On Wednesday, 30 July 2014 at 08:12:17 UTC, Rikki Cattermole wrote:
> On 30/07/2014 7:03 p.m., Kagamin wrote:
>> Making dmd generate coff would make more sense.
> +1
> Most of the code should already be present in dmd, which makes it far crazier not to.

What makes it craziest is that there's a COFF32 branch lying around that nobody merges:

http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmars-d@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com

It would be a far better use of Jonathan's time to get COFF32 merged and obsolete Optlink altogether.

On 30/07/2014 8:58 p.m., Joakim wrote:
> On Wednesday, 30 July 2014 at 08:12:17 UTC, Rikki Cattermole wrote:
>> On 30/07/2014 7:03 p.m., Kagamin wrote:
>>> Making dmd generate coff would make more sense.
>> +1
>> Most of the code should already be present in dmd, which makes it far
>> crazier not to.
>
> What makes it craziest is that there's a COFF32 branch lying around that
> nobody merges:
>
> http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmars-d@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com
>
>
> It would be a far better use of Jonathan's time to get COFF32 merged and
> obsolete Optlink altogether.

If we obsoleted the OMF format output we would need to have a free and distributed with PE-COFF linker. If we can do this, I think Walter might go along with it.

Unless of course we could convince Microsoft to have a download just for the linker. We could download that in e.g. the installer. Would be better than a full install.

On Wednesday, 30 July 2014 at 09:06:11 UTC, Rikki Cattermole wrote:
> On 30/07/2014 8:58 p.m., Joakim wrote:
>> On Wednesday, 30 July 2014 at 08:12:17 UTC, Rikki Cattermole wrote:
>>> On 30/07/2014 7:03 p.m., Kagamin wrote:
>>>> Making dmd generate coff would make more sense.
>>> +1
>>> Most of the code should already be present in dmd, which makes it far
>>> crazier not to.
>>
>> What makes it craziest is that there's a COFF32 branch lying around that
>> nobody merges:
>>
>> http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmars-d@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com
>>
>>
>> It would be a far better use of Jonathan's time to get COFF32 merged and
>> obsolete Optlink altogether.
>
> If we obsoleted the OMF format output we would need to have a free and distributed with PE-COFF linker. If we can do this, I think Walter might go along with it.
>
> Unless of course we could convince Microsoft to have a download just for the linker. We could download that in e.g. the installer. Would be better than a full install.

I don't think dmd comes with a COFF64 linker now, users are just told to install Visual Studio or the Windows SDK for a linker.  No reason you can't do the same with COFF32.  Optlink can stick around with OMF for a couple releases.  I suspect nobody would use it when given the choice of COFF32 support.

On 30/07/2014 9:17 p.m., Joakim wrote:
> On Wednesday, 30 July 2014 at 09:06:11 UTC, Rikki Cattermole wrote:
>> On 30/07/2014 8:58 p.m., Joakim wrote:
>>> On Wednesday, 30 July 2014 at 08:12:17 UTC, Rikki Cattermole wrote:
>>>> On 30/07/2014 7:03 p.m., Kagamin wrote:
>>>>> Making dmd generate coff would make more sense.
>>>> +1
>>>> Most of the code should already be present in dmd, which makes it far
>>>> crazier not to.
>>>
>>> What makes it craziest is that there's a COFF32 branch lying around that
>>> nobody merges:
>>>
>>> http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmars-d@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com
>>>
>>>
>>>
>>> It would be a far better use of Jonathan's time to get COFF32 merged and
>>> obsolete Optlink altogether.
>>
>> If we obsoleted the OMF format output we would need to have a free and
>> distributed with PE-COFF linker. If we can do this, I think Walter
>> might go along with it.
>>
>> Unless of course we could convince Microsoft to have a download just
>> for the linker. We could download that in e.g. the installer. Would be
>> better than a full install.
>
> I don't think dmd comes with a COFF64 linker now, users are just told to
> install Visual Studio or the Windows SDK for a linker. No reason you
> can't do the same with COFF32.  Optlink can stick around with OMF for a
> couple releases.  I suspect nobody would use it when given the choice of
> COFF32 support.

I'm in agreement with you about just getting people to install it. But the problem is, its not out of the box enough for Walters liking and I'm partially agreeing with him on this. At the end of the day, we don't really want to tell new people you have to also install x.

Also not to forget that we could also remove OUR implib versions of Windows Dlls. That would solve a lot of issues for people I bet.