digitalmars.D - All functions COMDAT on OSX

bitwise (6/6) Nov 15 2015 https://issues.dlang.org/show_bug.cgi?id=15342

Walter Bright (4/10) Nov 16 2015 It enables:

bitwise (25/40) Nov 16 2015 I understand what it's for, but it's incorrect behaviour to have

Marc =?UTF-8?B?U2Now7x0eg==?= (7/49) Nov 16 2015 FWIW, that's been in the source since somewhen between 2.025 and

bitwise (14/67) Nov 16 2015 Yeah... I'm wondering how much chaos it would cause to fix this,

Marc =?UTF-8?B?U2Now7x0eg==?= (5/18) Nov 17 2015 I'd say, just open a PR and see whether the auto-tester

bitwise <bitwise.pvt gmail.com> writes:

https://issues.dlang.org/show_bug.cgi?id=15342

DMD emits all functions as COMDAT on OSX.

I'm guessing this was originally a workaround of some kind...does 
anybody know the story?

Thanks,
     Bit

Nov 15 2015

Walter Bright <newshound2 digitalmars.com> writes:

On 11/15/2015 8:44 PM, bitwise wrote:
 https://issues.dlang.org/show_bug.cgi?id=15342

 DMD emits all functions as COMDAT on OSX.

 I'm guessing this was originally a workaround of some kind...does anybody know
 the story?

 Thanks,
      Bit

It enables:

1. the linker to remove duplicates (happens with templates and other things)
2. the linker to remove unreferenced COMDATs

Nov 16 2015

bitwise <bitwise.pvt gmail.com> writes:

On Monday, 16 November 2015 at 08:15:39 UTC, Walter Bright wrote:
 On 11/15/2015 8:44 PM, bitwise wrote:
 https://issues.dlang.org/show_bug.cgi?id=15342

 DMD emits all functions as COMDAT on OSX.

 I'm guessing this was originally a workaround of some 
 kind...does anybody know
 the story?

 Thanks,
      Bit

 It enables:

 1. the linker to remove duplicates (happens with templates and 
 other things)
 2. the linker to remove unreferenced COMDATs

I understand what it's for, but it's incorrect behaviour to have 
_all_ functions being emitted as comdat. Non-template functions 
shouldn't be coalesced in this way. If you compile the code 
example in the bug report with *any* compiler other than DMD/OSX, 
the example will fail as described, with a linker error. The 
example compares dmd/osx with gcc/osx, but the code will also 
fail with ldc/osx. And although I don't have time to check, I'm 
pretty sure it will fail with dmd/win as well.

If you look at the code I cited, this is obviously a hack:

<glue.c#L866-L870>
[...]
#if TARGET_OSX
     s->Sclass = SCcomdat;
#else
     s->Sclass = SCglobal;
#endif
     for (Dsymbol *p = fd->parent; p; p = p->parent) {
         if (p->isTemplateInstance()) {
             s->Sclass = SCcomdat;
             break;
         }
     }
[...]

     Bit

Nov 16 2015

Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:

On Monday, 16 November 2015 at 14:37:33 UTC, bitwise wrote:
 On Monday, 16 November 2015 at 08:15:39 UTC, Walter Bright 
 wrote:
 On 11/15/2015 8:44 PM, bitwise wrote:
 https://issues.dlang.org/show_bug.cgi?id=15342

 DMD emits all functions as COMDAT on OSX.

 I'm guessing this was originally a workaround of some 
 kind...does anybody know
 the story?

 Thanks,
      Bit

 It enables:

 1. the linker to remove duplicates (happens with templates and 
 other things)
 2. the linker to remove unreferenced COMDATs

 I understand what it's for, but it's incorrect behaviour to 
 have _all_ functions being emitted as comdat. Non-template 
 functions shouldn't be coalesced in this way. If you compile 
 the code example in the bug report with *any* compiler other 
 than DMD/OSX, the example will fail as described, with a linker 
 error. The example compares dmd/osx with gcc/osx, but the code 
 will also fail with ldc/osx. And although I don't have time to 
 check, I'm pretty sure it will fail with dmd/win as well.

 If you look at the code I cited, this is obviously a hack:

 <glue.c#L866-L870>
 [...]
 #if TARGET_OSX
     s->Sclass = SCcomdat;
 #else
     s->Sclass = SCglobal;
 #endif
     for (Dsymbol *p = fd->parent; p; p = p->parent) {
         if (p->isTemplateInstance()) {
             s->Sclass = SCcomdat;
             break;
         }
     }
 [...]

FWIW, that's been in the source since somewhen between 2.025 and 
2.026:
https://github.com/D-Programming-Language/dmd/commit/00337ef8d8c4c1c08da68f95963e2fe1658a49ec

Unfortunately there are no intermediate commits in the repo, 
because only released versions have been imported during the 
switch to Git.

Nov 16 2015

bitwise <bitwise.pvt gmail.com> writes:

On Monday, 16 November 2015 at 17:09:05 UTC, Marc Schütz wrote:
 On Monday, 16 November 2015 at 14:37:33 UTC, bitwise wrote:
 On Monday, 16 November 2015 at 08:15:39 UTC, Walter Bright 
 wrote:
 On 11/15/2015 8:44 PM, bitwise wrote:
 https://issues.dlang.org/show_bug.cgi?id=15342

 DMD emits all functions as COMDAT on OSX.

 I'm guessing this was originally a workaround of some 
 kind...does anybody know
 the story?

 Thanks,
      Bit

 It enables:

 1. the linker to remove duplicates (happens with templates 
 and other things)
 2. the linker to remove unreferenced COMDATs

 I understand what it's for, but it's incorrect behaviour to 
 have _all_ functions being emitted as comdat. Non-template 
 functions shouldn't be coalesced in this way. If you compile 
 the code example in the bug report with *any* compiler other 
 than DMD/OSX, the example will fail as described, with a 
 linker error. The example compares dmd/osx with gcc/osx, but 
 the code will also fail with ldc/osx. And although I don't 
 have time to check, I'm pretty sure it will fail with dmd/win 
 as well.

 If you look at the code I cited, this is obviously a hack:

 <glue.c#L866-L870>
 [...]
 #if TARGET_OSX
     s->Sclass = SCcomdat;
 #else
     s->Sclass = SCglobal;
 #endif
     for (Dsymbol *p = fd->parent; p; p = p->parent) {
         if (p->isTemplateInstance()) {
             s->Sclass = SCcomdat;
             break;
         }
     }
 [...]

 FWIW, that's been in the source since somewhen between 2.025 
 and 2.026:
 https://github.com/D-Programming-Language/dmd/commit/00337ef8d8c4c1c08da68f95963e2fe1658a49ec

 Unfortunately there are no intermediate commits in the repo, 
 because only released versions have been imported during the 
 switch to Git.

Yeah... I'm wondering how much chaos it would cause to fix this, 
because it's a blocking issue for fixing shared libs on OSX.

To support shared libraries, I'de have to add a unique linux 
style global ctor/dtor to each module. LDC already does this. 
There is no alternative solution.

I could special case the ctor/dtors in DMD not to be COMDAT, but 
the effect would be the same as fixing the bug anyways, which 
would be that people would get linker errors if they linked(or 
are currently linking) the same module multiple times in their 
binary.

This breakage is necessary to implement shared libraries, and 
facilitate proper linking behaviour.

     Bit

Nov 16 2015

Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:

On Monday, 16 November 2015 at 17:59:21 UTC, bitwise wrote:
 Yeah... I'm wondering how much chaos it would cause to fix 
 this, because it's a blocking issue for fixing shared libs on 
 OSX.

 To support shared libraries, I'de have to add a unique linux 
 style global ctor/dtor to each module. LDC already does this. 
 There is no alternative solution.

 I could special case the ctor/dtors in DMD not to be COMDAT, 
 but the effect would be the same as fixing the bug anyways, 
 which would be that people would get linker errors if they 
 linked(or are currently linking) the same module multiple times 
 in their binary.

 This breakage is necessary to implement shared libraries, and 
 facilitate proper linking behaviour.

I'd say, just open a PR and see whether the auto-tester 
complains. If it works, then supporting shared libraries is worth 
the risk. Most likely it was just a workaround for a problem with 
an ancient version of OS X.

Nov 17 2015

D Programming

C/C++ Programming

Other

digitalmars.D - All functions COMDAT on OSX