www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - All functions COMDAT on OSX

reply 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
parent reply 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
parent reply 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
parent reply 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
parent reply 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
parent 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