www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Bootstrap crash on Solaris 2.11/5.11 - uninitialized mem access

reply "Rick V" <rick snowlight.net> writes:
So, I decided to get into D at the behest of a few of my colleagues.

Sure. Why not? Tried bootstrapping on a netbsd system, only got as far as 
building a freestanding Symantec/DMD 2.067.1 because NetBSD/OpenBSD support 
in druntime is still in progress.

Switched to my Solaris box, bootstrapped LDC 0.17, druntime-ldc and 
phobos-ldc 2.068 for both 32-bit and 64-bit variants. (Both are native 
64-bit compilers, as the included LLVM 4.0 is.)

The *new* LDC crashes when compiling anything, at 
registerPredefinedVersions(), while calling 
VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets 
random garbage at dmd.identifier.Identifier.idPool(const(char)[]).
Jan 01
next sibling parent "Rick V" <rick snowlight.net> writes:
Forgot to mention that the new LDC is either of HEAD or the 1.13.0 
release--neither one works.

"Rick V"  wrote in message news:q0fgef$hij$1 digitalmars.com...

So, I decided to get into D at the behest of a few of my colleagues.

Sure. Why not? Tried bootstrapping on a netbsd system, only got as far as
building a freestanding Symantec/DMD 2.067.1 because NetBSD/OpenBSD support
in druntime is still in progress.

Switched to my Solaris box, bootstrapped LDC 0.17, druntime-ldc and
phobos-ldc 2.068 for both 32-bit and 64-bit variants. (Both are native
64-bit compilers, as the included LLVM 4.0 is.)

The *new* LDC crashes when compiling anything, at
registerPredefinedVersions(), while calling
VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets
random garbage at dmd.identifier.Identifier.idPool(const(char)[]). 
Jan 01
prev sibling parent reply kinke <noone nowhere.com> writes:
On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
 The *new* LDC crashes when compiling anything, at 
 registerPredefinedVersions(), while calling 
 VersionCondition::addPredefinedGlobalIdent("DMD"), but the D 
 side gets random garbage at 
 dmd.identifier.Identifier.idPool(const(char)[]).
Sounds familiar; this is probably due to a buggy linker (see 1.13 release notes; LDC defaults to gold because older bfd wrongly strips ModuleInfos). So try gold or a newer bfd (or lld).
Jan 01
parent reply "Rick V" <rick snowlight.net> writes:
Not an option; LLD is installed, but the LDC 0.17 bootstrap unconditionally 
uses Solaris LD...gold is not an option because of invalid linker flags

"kinke"  wrote in message news:snpqurmvtvmvfzpijmcu forum.dlang.org...

On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
 The *new* LDC crashes when compiling anything, at 
 registerPredefinedVersions(), while calling 
 VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets 
 random garbage at dmd.identifier.Identifier.idPool(const(char)[]).
Sounds familiar; this is probably due to a buggy linker (see 1.13 release notes; LDC defaults to gold because older bfd wrongly strips ModuleInfos). So try gold or a newer bfd (or lld).
Jan 01
parent reply "David Nadlinger" <code klickverbot.at> writes:
On 2 Jan 2019, at 0:32, Rick V via digitalmars-d-ldc wrote:
 On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
 The *new* LDC crashes when compiling anything, at 
 registerPredefinedVersions(), while calling 
 VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side 
 gets random garbage at 
 dmd.identifier.Identifier.idPool(const(char)[]).
Sounds familiar; this is probably due to a buggy linker (see 1.13 release notes; LDC defaults to gold because older bfd wrongly strips ModuleInfos). So try gold or a newer bfd (or lld).
So just to clarify, is this the v1.13 binary crashing as built by v0.17, or a compiler built by v1.13? — David
Jan 02
parent reply "Rick V" <rick snowlight.net> writes:
It would be the newly-compiled v1.13, as built by 0.17.
LDC 0.17 calls either of GCC 6, 8, or Oracle DevStudio C 12u1 to perform 
final link edits.
0.17 can build D 2.068 apps correctly.
1.13 cannot even bootstrap its own Druntime 2.084.

-rick

"David Nadlinger"  wrote in message 
news:mailman.6172.1546488631.29801.digitalmars-d-ldc puremagic.com...

On 2 Jan 2019, at 0:32, Rick V via digitalmars-d-ldc wrote:
 On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
 The *new* LDC crashes when compiling anything, at 
 registerPredefinedVersions(), while calling 
 VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets 
 random garbage at dmd.identifier.Identifier.idPool(const(char)[]).
Sounds familiar; this is probably due to a buggy linker (see 1.13 release notes; LDC defaults to gold because older bfd wrongly strips ModuleInfos). So try gold or a newer bfd (or lld).
So just to clarify, is this the v1.13 binary crashing as built by v0.17, or a compiler built by v1.13? — David
Jan 02
parent reply "Rick V" <rick snowlight.net> writes:
edit:....and these C++ compilers are hardcoded to call the native Oracle 
DevStudio link editor
even GCC recommends using the Developer Studio binutils over its own on 
Solaris...

-rick

"Rick V"  wrote in message news:q0k70o$rgi$1 digitalmars.com...

It would be the newly-compiled v1.13, as built by 0.17.
LDC 0.17 calls either of GCC 6, 8, or Oracle DevStudio C 12u1 to perform
final link edits.
0.17 can build D 2.068 apps correctly.
1.13 cannot even bootstrap its own Druntime 2.084.

-rick

"David Nadlinger"  wrote in message
news:mailman.6172.1546488631.29801.digitalmars-d-ldc puremagic.com...

On 2 Jan 2019, at 0:32, Rick V via digitalmars-d-ldc wrote:
 On Tuesday, 1 January 2019 at 10:46:28 UTC, Rick V wrote:
 The *new* LDC crashes when compiling anything, at 
 registerPredefinedVersions(), while calling 
 VersionCondition::addPredefinedGlobalIdent("DMD"), but the D side gets 
 random garbage at dmd.identifier.Identifier.idPool(const(char)[]).
Sounds familiar; this is probably due to a buggy linker (see 1.13 release notes; LDC defaults to gold because older bfd wrongly strips ModuleInfos). So try gold or a newer bfd (or lld).
So just to clarify, is this the v1.13 binary crashing as built by v0.17, or a compiler built by v1.13? — David
Jan 02
parent reply kinke <noone nowhere.com> writes:
On Thursday, 3 January 2019 at 05:39:39 UTC, Rick V wrote:
 edit:....and these C++ compilers are hardcoded to call the 
 native Oracle DevStudio link editor
 even GCC recommends using the Developer Studio binutils over 
 its own on Solaris...
I have no idea about and no interest in Solaris and its linker situation. Anyway, there have been changes with 1.13 wrt. ModuleInfos (affecting run module ctors, which is the problem you are seeing), so you shouldn't have any issues with 1.12. Recent bfd on Linux works fine with v1.13, e.g., the one shipping with Ubuntu 18.04; ancient gold from Ubuntu 14.04 works fine too.
Jan 03
next sibling parent kinke <noone nowhere.com> writes:
On Thursday, 3 January 2019 at 18:09:23 UTC, kinke wrote:
 I have no idea about and no interest in Solaris and its linker 
 situation. Anyway, there have been changes with 1.13 wrt. 
 ModuleInfos (affecting run module ctors, which is the problem 
 you are seeing), so you shouldn't have any issues with 1.12. 
 Recent bfd on Linux works fine with v1.13, e.g., the one 
 shipping with Ubuntu 18.04; ancient gold from Ubuntu 14.04 
 works fine too.
Just for completeness: with v1.12 as host compiler for 1.13/master, you have * the `-gcc` option to select the C compiler for linking (gcc/clang; might be available in 0.17 too), * the `-linker=blub` option, which translates to `-fuse-ld=blub` in the gcc/clang command line, and * the `-Xcc` option for arbitrary gcc/clang command line options.
Jan 03
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On 3 Jan 2019, at 18:09, kinke via digitalmars-d-ldc wrote:
 I have no idea about and no interest in Solaris and its linker 
 situation. Anyway, there have been changes with 1.13 wrt. ModuleInfos 
 (affecting run module ctors, which is the problem you are seeing)
Rick is using a compiler (doesn't matter that it's 1.13) compiled by 0.17, though. Also, any regressions regarding --gc-sections shouldn't affect Solaris, as the option isn't even active there. In fact, I think Solaris even uses the old _Dmodule_ref scheme for module registration. That being said, if the symptoms match the ModuleInfo-related issues you have been seeing, it's reasonable to suspect another issue affecting `ModuleInfo`s or static constructors on Solaris. —David
Jan 03
parent reply kinke <noone nowhere.com> writes:
On Thursday, 3 January 2019 at 19:32:57 UTC, David Nadlinger 
wrote:
 Rick is using a compiler (doesn't matter that it's 1.13) 
 compiled by 0.17, though. Also, any regressions regarding 
 --gc-sections shouldn't affect Solaris, as the option isn't 
 even active there. In fact, I think Solaris even uses the old 
 _Dmodule_ref scheme for module registration.

 That being said, if the symptoms match the ModuleInfo-related 
 issues you have been seeing, it's reasonable to suspect another 
 issue affecting `ModuleInfo`s or static constructors on Solaris.
Yes, you're absolutely right, I came to the same conclusion after my reply. ;) I have no idea about the state of Solaris support, but I'm pretty sure it hasn't been touched in years, so I guess the situation hasn't improved since v0.17.
Jan 03
parent reply Rick V <rick snowlight.net> writes:
Now that I got my hands on the current release of Oracle 
DevStudio (5.15/12.6), I'm going to build a GNU CC configured to 
use GAS and GLD (all the GNU tools are prefixed here)
I mean, language support is *there*, it's the underlying plumbing 
that's driving me nuts
(and hoping that NetBSD support is advancing soon!)

Cheers
Rick

On Thursday, 3 January 2019 at 22:25:12 UTC, kinke wrote:
 On Thursday, 3 January 2019 at 19:32:57 UTC, David Nadlinger 
 wrote:
 Rick is using a compiler (doesn't matter that it's 1.13) 
 compiled by 0.17, though. Also, any regressions regarding 
 --gc-sections shouldn't affect Solaris, as the option isn't 
 even active there. In fact, I think Solaris even uses the old 
 _Dmodule_ref scheme for module registration.

 That being said, if the symptoms match the ModuleInfo-related 
 issues you have been seeing, it's reasonable to suspect 
 another issue affecting `ModuleInfo`s or static constructors 
 on Solaris.
Yes, you're absolutely right, I came to the same conclusion after my reply. ;) I have no idea about the state of Solaris support, but I'm pretty sure it hasn't been touched in years, so I guess the situation hasn't improved since v0.17.
Jan 06
parent "Rick V" <rick snowlight.net> writes:
update: replaced system GLD without plugin support, etc with custom GLD
build works fine now

Cheers
Rick

"Rick V"  wrote in message news:xkjellyzzpgfidpzralc forum.dlang.org... 

Now that I got my hands on the current release of Oracle 
DevStudio (5.15/12.6), I'm going to build a GNU CC configured to 
use GAS and GLD (all the GNU tools are prefixed here)
I mean, language support is *there*, it's the underlying plumbing 
that's driving me nuts
(and hoping that NetBSD support is advancing soon!)

Cheers
Rick

On Thursday, 3 January 2019 at 22:25:12 UTC, kinke wrote:
 On Thursday, 3 January 2019 at 19:32:57 UTC, David Nadlinger 
 wrote:
 Rick is using a compiler (doesn't matter that it's 1.13) 
 compiled by 0.17, though. Also, any regressions regarding 
 --gc-sections shouldn't affect Solaris, as the option isn't 
 even active there. In fact, I think Solaris even uses the old 
 _Dmodule_ref scheme for module registration.

 That being said, if the symptoms match the ModuleInfo-related 
 issues you have been seeing, it's reasonable to suspect 
 another issue affecting `ModuleInfo`s or static constructors 
 on Solaris.
Yes, you're absolutely right, I came to the same conclusion after my reply. ;) I have no idea about the state of Solaris support, but I'm pretty sure it hasn't been touched in years, so I guess the situation hasn't improved since v0.17.
Jan 08