digitalmars.D.bugs - [Issue 9969] New: dmd ABI mistake (cfloat static array initialisation)
- d-bugmail puremagic.com (64/64) Apr 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9969
- d-bugmail puremagic.com (14/14) Apr 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9969
- d-bugmail puremagic.com (9/15) Apr 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9969
- d-bugmail puremagic.com (7/18) Apr 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9969
- d-bugmail puremagic.com (15/26) Apr 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9969
- d-bugmail puremagic.com (18/40) Apr 20 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9969
- d-bugmail puremagic.com (27/30) Apr 21 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9969
http://d.puremagic.com/issues/show_bug.cgi?id=9969 Summary: dmd ABI mistake (cfloat static array initialisation) Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: john.loughran.colvin gmail.com 16:22:40 BST --- test.d: import std.stdio; void main() { cfloat a[2]; } $ dmd test.d $ ./test Segmentation fault (core dumped) The problem is here: 0000000000000000 <_Dmain>: 0: 55 push rbp 1: 48 8b ec mov rbp,rsp 4: 48 83 ec 10 sub rsp,0x10 8: 48 83 ec 08 sub rsp,0x8 c: 48 be 02 00 00 00 00 movabs rsi,0x2 13: 00 00 00 18: R_X86_64_PC32 .rodata-0x4 1c: 48 8d 7d f0 lea rdi,[rbp-0x10] 20: e8 00 00 00 00 call 25 <_Dmain+0x25> 21: R_X86_64_PC32 _memset64-0x4 25: 48 83 c4 10 add rsp,0x10 29: 31 c0 xor eax,eax 2b: c9 leave 2c: c3 ret 2d: 0f 1f 00 nop DWORD PTR [rax] 0000000000000000 <_memset64>: 0: 55 push rbp 1: 48 8b ec mov rbp,rsp 4: 48 83 ec 10 sub rsp,0x10 8: 49 89 f8 mov r8,rdi b: 49 89 f1 mov r9,rsi e: 48 89 f8 mov rax,rdi 11: 49 8d 0c d0 lea rcx,[r8+rdx*8] 15: 4c 3b c1 cmp r8,rcx 18: 73 0c jae 26 <_memset64+0x26> 1a: 4d 89 08 mov QWORD PTR [r8],r9 1d: 49 83 c0 08 add r8,0x8 21: 49 39 c8 cmp r8,rcx 24: 72 f4 jb 1a <_memset64+0x1a> 26: 48 8b e5 mov rsp,rbp 29: 5d pop rbp 2a: c3 ret long *_memset64(long *p, long value, size_t count) _memset64 is extern(C). Dmd passes "p" correctly, but then tries to pass "value" on the stack and passes the value for "count" as the second argument. _memset64 attempts to use rdx as the count, which is garbage. Hence, segfault. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9969 Maxim Fomin <maxim maxim-fomin.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxim maxim-fomin.ru --- Looks like an issue 9449. I think the problem isn't "ABI mistake" (or a codegen bug as often mentioned here - many people who can spot an error from asm output tend to blame backend) but absence of crosstalk between how dmd assumes memset functions look like and how they are actually defined in druntime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9969 18:14:12 BST ---Looks like an issue 9449. I think the problem isn't "ABI mistake" (or a codegen bug as often mentioned here - many people who can spot an error from asm output tend to blame backend) but absence of crosstalk between how dmd assumes memset functions look like and how they are actually defined in druntime.I'm confused as to how trying to pass a variable on the stack to an extern(C) function with less than 6 arguments on linux x64 is not a codegen error of some sorts. It's using the wrong calling convention... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9969 18:16:49 BST ---s/codegen/ABI -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Looks like an issue 9449. I think the problem isn't "ABI mistake" (or a codegen bug as often mentioned here - many people who can spot an error from asm output tend to blame backend) but absence of crosstalk between how dmd assumes memset functions look like and how they are actually defined in druntime.I'm confused as to how trying to pass a variable on the stack to an extern(C) function with less than 6 arguments on linux x64 is not a codegen error of some sorts. It's using the wrong calling convention...
Apr 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9969 ---I do not think that if you can see that compiler passes arguments wrong you may conclude that it is codegen or ABI bug. That is what actually often happens: somebody see error in asm output and blames backend while the problem is really in frontend. From what I know after debugging issue 9449 there is likely error in scope of AssignExp::toElem (https://github.com/D-Programming-Language/dmd/blob/master/src/e2ir.c#L2688) (or setArray()) which does not handle properly cases like this. The problem is in frontend assumption that druntime defines memset function as taking dynamic array. The backend just does what it is told to generate. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Looks like an issue 9449. I think the problem isn't "ABI mistake" (or a codegen bug as often mentioned here - many people who can spot an error from asm output tend to blame backend) but absence of crosstalk between how dmd assumes memset functions look like and how they are actually defined in druntime.I'm confused as to how trying to pass a variable on the stack to an extern(C) function with less than 6 arguments on linux x64 is not a codegen error of some sorts. It's using the wrong calling convention...
Apr 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9969 23:18:54 BST ---I concede that there may well be a frontend problem as well, but in my limited experience a properly functioning backend should never emit the code we see here. System V dictates that the first 6 integer/pointer arguments passed in RDI, RSI, RDX, RCX, R8, and R9, the first 8 floating point arguments are passed in XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6 and XMM7 an any further arguments are passed on the stack. If the compiler emits code passing 3 arguments to an extern(C) function, 2 in ESI and EDI and 1 on the stack, then it's a problem relating to the ABI. The actual signature/behaviour of the target function is irrelevant, AFAIK there is no possible System V compliant target function for which that argument passing would be correct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------I do not think that if you can see that compiler passes arguments wrong you may conclude that it is codegen or ABI bug. That is what actually often happens: somebody see error in asm output and blames backend while the problem is really in frontend. From what I know after debugging issue 9449 there is likely error in scope of AssignExp::toElem (https://github.com/D-Programming-Language/dmd/blob/master/src/e2ir.c#L2688) (or setArray()) which does not handle properly cases like this. The problem is in frontend assumption that druntime defines memset function as taking dynamic array. The backend just does what it is told to generate.Looks like an issue 9449. I think the problem isn't "ABI mistake" (or a codegen bug as often mentioned here - many people who can spot an error from asm output tend to blame backend) but absence of crosstalk between how dmd assumes memset functions look like and how they are actually defined in druntime.I'm confused as to how trying to pass a variable on the stack to an extern(C) function with less than 6 arguments on linux x64 is not a codegen error of some sorts. It's using the wrong calling convention...
Apr 20 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9969 Maxim Fomin <maxim maxim-fomin.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |critical ---I concede that there may well be a frontend problem as well, but in my limited experience a properly functioning backend should never emit the code we see here.What backend generates isn't determined only by it, bugs in frontend may lead to incorrect instructions. Look at: extern(C) int printf(const char*, ... ); extern(C) long *_memset64(long *p, long value, size_t count); void main() { long[2] arr = void; _memset64(arr.ptr, 1, 2); printf("%d %d\n", arr[0], arr[1]); //cfloat[2] bug; } and _Dmain. In this case call to memset is constructed by CallExp and things are done right, but in case of cfloat[2] call is constructed by AssignExp and setArray (https://github.com/D-Programming-Language/dmd/blob/master/src/e2ir.c#L757) and invalid code is generated. Anyway, this is critical. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 21 2013