www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 32-bit DMD compiled programs prints "segmentation fault"

reply Gilmar =?UTF-8?B?SsO6bmlvcg==?= <gilmartaj gmail.com> writes:
Hello, D programs compiled with 32-bit DMD are not working. I 
compiled with dmd and also tested rdmd using version 2.086.0-0 
for both 32-bit and the 64-bit with -m32 directive, and it didn't 
work. I also tested the nightly version I downloaded today and 
the execution continues to print "segmentation fault (core 
dumped)". The same error does NOT occur when using LDC.
Nov 01
parent reply Seb <seb wilzba.ch> writes:
On Friday, 1 November 2019 at 21:16:23 UTC, Gilmar Júnior wrote:
 Hello, D programs compiled with 32-bit DMD are not working. I 
 compiled with dmd and also tested rdmd using version 2.086.0-0 
 for both 32-bit and the 64-bit with -m32 directive, and it 
 didn't work. I also tested the nightly version I downloaded 
 today and the execution continues to print "segmentation fault 
 (core dumped)". The same error does NOT occur when using LDC.
This unfortunately is a well-known issue: https://issues.dlang.org/show_bug.cgi?id=19116 tl;dr: use LDC. It's better maintained, faster, has support for tons of architectures etc. Alternatively, you could also switch to ld.gold which you probably want to do anyhow if you can (faster link times!) or x86_64.
Nov 01
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2019 4:03 PM, Seb wrote:
 On Friday, 1 November 2019 at 21:16:23 UTC, Gilmar Júnior wrote:
 Hello, D programs compiled with 32-bit DMD are not working. I compiled with 
 dmd and also tested rdmd using version 2.086.0-0 for both 32-bit and the 
 64-bit with -m32 directive, and it didn't work. I also tested the nightly 
 version I downloaded today and the execution continues to print "segmentation 
 fault (core dumped)". The same error does NOT occur when using LDC.
This unfortunately is a well-known issue: https://issues.dlang.org/show_bug.cgi?id=19116 tl;dr: use LDC. It's better maintained, faster, has support for tons of architectures etc. Alternatively, you could also switch to ld.gold which you probably want to do anyhow if you can (faster link times!) or x86_64.
Why does the PIE code gen work fine on Linux but not Debian? (It passes all the 32 bit tests on the autotester.)
Nov 01
parent reply Suleyman <sahmi.soulaimane gmail.com> writes:
On Saturday, 2 November 2019 at 00:04:27 UTC, Walter Bright wrote:
 Why does the PIE code gen work fine on Linux but not Debian?

 (It passes all the 32 bit tests on the autotester.)
GCC 6 enabled PIE by default, you have to disable it manually with `-no-pie`. The auto-tester uses and ancient GCC version which is not affected.
Nov 02
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/2/2019 10:06 AM, Suleyman wrote:
 On Saturday, 2 November 2019 at 00:04:27 UTC, Walter Bright wrote:
 Why does the PIE code gen work fine on Linux but not Debian?

 (It passes all the 32 bit tests on the autotester.)
GCC 6 enabled PIE by default, you have to disable it manually with `-no-pie`. The auto-tester uses and ancient GCC version which is not affected.
Yes, but I'd like to know exactly what code sequence generated by dmd is not working, vs what ldc is generating that does work.
Nov 02
parent Suleyman <sahmi.soulaimane gmail.com> writes:
On Sunday, 3 November 2019 at 04:36:50 UTC, Walter Bright wrote:
 On 11/2/2019 10:06 AM, Suleyman wrote:
 On Saturday, 2 November 2019 at 00:04:27 UTC, Walter Bright 
 wrote:
 Why does the PIE code gen work fine on Linux but not Debian?

 (It passes all the 32 bit tests on the autotester.)
GCC 6 enabled PIE by default, you have to disable it manually with `-no-pie`. The auto-tester uses and ancient GCC version which is not affected.
Yes, but I'd like to know exactly what code sequence generated by dmd is not working, vs what ldc is generating that does work.
There is nothing wrong with DMD, the problem is in the coordination with the linker. For example: ``` extern(C): void printf(const char*, ...); int g = 10; void main() { printf("OK\n"); int i = g; // crash printf("%d\n", i); } ``` Note: compile the program with -betterC to avoid linking druntime. This program crashes, but if you add the -fPIC switch it works. LDC has -fPIC by default.
Nov 03
prev sibling parent reply Exil <Exil gmall.com> writes:
On Friday, 1 November 2019 at 23:03:23 UTC, Seb wrote:
 tl;dr: use LDC. It's better maintained,
How many people are maintaining LDC in comparison to DMD?
Nov 02
parent reply Suleyman <sahmi.soulaimane gmail.com> writes:
On Sunday, 3 November 2019 at 00:15:29 UTC, Exil wrote:
 On Friday, 1 November 2019 at 23:03:23 UTC, Seb wrote:
 tl;dr: use LDC. It's better maintained,
How many people are maintaining LDC in comparison to DMD?
That wouldn't be a fair question because frontend development is backend agnostic, and the backend of LDC is a separate project project LLVM.
Nov 02
parent reply Exil <Exil gmall.com> writes:
On Sunday, 3 November 2019 at 04:34:18 UTC, Suleyman wrote:
 On Sunday, 3 November 2019 at 00:15:29 UTC, Exil wrote:
 On Friday, 1 November 2019 at 23:03:23 UTC, Seb wrote:
 tl;dr: use LDC. It's better maintained,
How many people are maintaining LDC in comparison to DMD?
That wouldn't be a fair question because frontend development is backend agnostic, and the backend of LDC is a separate project project LLVM.
Those kinds of decisions are in part what affect the maintainability of a project, so it would be a fair assessment to include.
Nov 03
parent reply Suleyman <sahmi.soulaimane gmail.com> writes:
On Sunday, 3 November 2019 at 18:35:41 UTC, Exil wrote:
 [...]
Those kinds of decisions are in part what affect the maintainability of a project, so it would be a fair assessment to include.
Let's just say it's a lot less than LLVM maintainers. Usually the backend just works but we could use some more backend contributors. Translating the backend from C to D was a step in the right direction, but it still looks like C. Maybe it can be modernized. But Walter has a pile of more important work at all levels, language, frontend, and backend, so lesser the dependence on Walter is except for getting approval the more can be achieved in parallel.
Nov 03
parent reply Exil <Exil gmall.com> writes:
On Sunday, 3 November 2019 at 19:28:41 UTC, Suleyman wrote:
 On Sunday, 3 November 2019 at 18:35:41 UTC, Exil wrote:
 [...]
Those kinds of decisions are in part what affect the maintainability of a project, so it would be a fair assessment to include.
Let's just say it's a lot less than LLVM maintainers.
LLVM developers don't work specifically on LDC do they?
 Usually the backend just works but we could use some more 
 backend contributors.
It doesn't for me, I come across quite a few bugs due to the backend.
 Translating the backend from C to D was a step in the right 
 direction, but it still looks like C. Maybe it can be 
 modernized. But Walter has a pile of more important work at all 
 levels, language, frontend, and backend, so lesser the 
 dependence on Walter is except for getting approval the more 
 can be achieved in parallel.
Modernizing isnt the issue. Wouldn't you agree that LLVM has the absolute least dependence on Walter :)? All arguments you've made are all basically why LDC is the better option than anything that could be done with a custom backend. Its just a waste of resources, and the quality of LDC in comparison to DMD speaks volumes, especially when you consider LDC is maintained mostly by a single individual.
Nov 04
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Nov 05, 2019 at 02:55:58AM +0000, Exil via Digitalmars-d wrote:
 On Sunday, 3 November 2019 at 19:28:41 UTC, Suleyman wrote:
[...]
 Translating the backend from C to D was a step in the right
 direction, but it still looks like C. Maybe it can be modernized.
 But Walter has a pile of more important work at all levels,
 language, frontend, and backend, so lesser the dependence on Walter
 is except for getting approval the more can be achieved in parallel.
Modernizing isnt the issue. Wouldn't you agree that LLVM has the absolute least dependence on Walter :)? All arguments you've made are all basically why LDC is the better option than anything that could be done with a custom backend. Its just a waste of resources, and the quality of LDC in comparison to DMD speaks volumes, especially when you consider LDC is maintained mostly by a single individual.
For the past several releases now, LDC has been closely tracking the latest DMD releases. If codegen quality is important to you, just use LDC instead. You won't miss much at all. I've been considering to do that myself as well (in fact, one of my projects now defaults to LDC, and it may well be that I'll start using LDC by default sometime in the near future). I really only use DMD for one-off script-like programs and for Phobos bugfixing these days, or where performance isn't a top priority. I've repeated many times that DMD consistently produces binaries that run 20-30% slower than binaries produced by LDC (for CPU-intensive tasks). So where performance or codegen quality is an issue, I recommend just using LDC completely. It's not so easy to convince Walter to give up the backend that he's been working on for decades. :-D And he doesn't really need to since we have LDC, and LDC has been closely tracking DMD releases so staying up-to-date with latest D developments isn't even a big issue anymore. (LDC's frontend is identical to DMD's so there's no difference there.) T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain
Nov 04
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 5 November 2019 at 06:38:24 UTC, H. S. Teoh wrote:
 It's not so easy to convince Walter to give up the backend that 
 he's been working on for decades.
dmd is still significantly faster to run and to recompile!
 DMD releases so staying up-to-date with latest D developments 
 isn't even a big issue anymore. (LDC's frontend is identical to 
 DMD's so there's no difference there.)
That's not quite true. They share about 98% of the code, but that remaining 2% can be significant at times. For example, ldc's extern(Objective-C) lacks much of the stuff dmd's have, since that's part of that 2% glue code that is compiler specific.
Nov 05
next sibling parent reply kinke <kinke gmx.net> writes:
On Tuesday, 5 November 2019 at 12:11:24 UTC, Adam D. Ruppe wrote:
 dmd is still significantly faster to run
Without `-O -release`, otherwise LDC is usually faster.
 and to recompile!
Depends on what you are working on. If it's just the frontend, then recompilation should take exactly as much time as DMD with appropriate settings. If it's just a .cpp file, then it's fast as well; if it's a C++ header file included by many .cpp's, then it can take some time.
 (LDC's frontend is identical to DMD's so there's no difference 
 there.)
That's not quite true. They share about 98% of the code, but that remaining 2% can be significant at times.
The glue code is much more than e.g. gluelayer.d and objc_glue.d; at its core, LDC and GDC are glue code, translating the frontend's AST to the LLVM/gcc intermediate representation. It doesn't help that DMD's source tree doesn't clearly separate frontend and glue code (which includes e2ir.d, s2ir.d etc.).
Nov 05
next sibling parent kinke <kinke gmx.net> writes:
On Tuesday, 5 November 2019 at 13:32:22 UTC, kinke wrote:
 Without `-O -release`, otherwise LDC is usually faster.
Sorry, should have been `-O -inline`.
Nov 05
prev sibling parent kinke <noone nowhere.com> writes:
On Tuesday, 5 November 2019 at 13:32:22 UTC, kinke wrote:
 On Tuesday, 5 November 2019 at 12:11:24 UTC, Adam D. Ruppe
 They share about 98% of the code, but that remaining 2% can be 
 significant at times.
The glue code is much more [...]
To roughly quantize that (I got interested myself), counting lines of code with scc [1], in the ldc src dir: scc dmd (frontend): 127,960 LOC scc driver gen ir: 37,136 LOC So the ratio isn't 98:2, but rather something like 77.5:22.5, which is quite a difference. [1] https://github.com/boyter/scc
Nov 05
prev sibling parent reply Exil <Exil gmall.com> writes:
On Tuesday, 5 November 2019 at 12:11:24 UTC, Adam D. Ruppe wrote:
 On Tuesday, 5 November 2019 at 06:38:24 UTC, H. S. Teoh wrote:
 It's not so easy to convince Walter to give up the backend 
 that he's been working on for decades.
dmd is still significantly faster to run and to recompile!
If that's truly important it can be done with LLVM. Jai uses LLVM and compiles significantly faster than D.
Nov 05
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 6 November 2019 at 03:13:46 UTC, Exil wrote:
 On Tuesday, 5 November 2019 at 12:11:24 UTC, Adam D. Ruppe 
 wrote:
 On Tuesday, 5 November 2019 at 06:38:24 UTC, H. S. Teoh wrote:
 It's not so easy to convince Walter to give up the backend 
 that he's been working on for decades.
dmd is still significantly faster to run and to recompile!
If that's truly important it can be done with LLVM. Jai uses LLVM and compiles significantly faster than D.
How do you know how fast Jai compiles? I thought it hadn't been released yet? Been waiting what seems like years to try it out.
Nov 05
parent reply Ethan <gooberman gmail.com> writes:
On Wednesday, 6 November 2019 at 06:01:31 UTC, Jonathan Marler 
wrote:
 How do you know how fast Jai compiles?  I thought it hadn't 
 been released yet?  Been waiting what seems like years to try 
 it out.
When I spoke to Jonathan Blow in person about Jai a couple of years back, he was quite open about performance and issues surrounding what he was doing. I'd be inclined to take him at his word when he talks about speed here.
Nov 06
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 6 November 2019 at 08:33:44 UTC, Ethan wrote:
 On Wednesday, 6 November 2019 at 06:01:31 UTC, Jonathan Marler 
 wrote:
 How do you know how fast Jai compiles?  I thought it hadn't 
 been released yet?  Been waiting what seems like years to try 
 it out.
When I spoke to Jonathan Blow in person about Jai a couple of years back, he was quite open about performance and issues surrounding what he was doing. I'd be inclined to take him at his word when he talks about speed here.
He said it compiles significantly faster than D?
Nov 06
parent reply Ethan <gooberman gmail.com> writes:
On Wednesday, 6 November 2019 at 08:38:12 UTC, Jonathan Marler 
wrote:
 He said it compiles significantly faster than D?
Not to me. But it's not hard to write equivalent code to his examples in D and get your own times to compare to his. If you compile on similar hardware, you'll get a good idea. I'd also expect his compile-time code execution engine to be in a better state that DMD's CTFE engine is currently (but Stefan is working on fixing that).
Nov 06
parent Exil <Exil gmall.com> writes:
On Wednesday, 6 November 2019 at 09:17:42 UTC, Ethan wrote:
 On Wednesday, 6 November 2019 at 08:38:12 UTC, Jonathan Marler 
 wrote:
 He said it compiles significantly faster than D?
Not to me. But it's not hard to write equivalent code to his examples in D and get your own times to compare to his. If you compile on similar hardware, you'll get a good idea.
He's building a game with Jai that compile in under a second. Small examples aren't indicative of how fast a compiler can compile when projects start getting larger. D isn't fast even with smaller examples if you include the wrong standard library modules.
 I'd also expect his compile-time code execution engine to be in 
 a better state that DMD's CTFE engine is currently (but Stefan 
 is working on fixing that).
"New CTFE" has been a WIP for years. I did take a look at it a while back and I'm not surprised it's taking so long to implement. It might very well be a few more years before it gets completed, and I can see it being really unstable when it does eventually get to that point.
Nov 06