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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019