Re: Two ways of receiving arrays on the C ABI
On Tuesday, 20 October 2020 at 00:16:48 UTC, Ali Çehreli wrote: On the D side, both of the following extern(C) functions take the same arguments. https://github.com/dlang/dmd/pull/8120 there are issues with structs. Not sure about length/ptr.
Two ways of receiving arrays on the C ABI
On the D side, both of the following extern(C) functions take the same
arguments.
1) func1 takes .length and .ptr implicitly as parts of a D array:
extern(C)
void func1(int[] arr) {
assert(arr.equal(3.iota));
}
2) func2 takes .length and .ptr separately and then makes a slice
explicitly:
extern(C)
void func2(size_t length, int * ptr) {
auto arr = ptr[0..length];
assert(arr.equal(3.iota));
}
C side declares and calls both of them the same way:
void func1(size_t length, int * ptr);
void func2(size_t length, int * ptr);
int arr[] = { 0, 1, 2 };
func1(3, arr);
func2(3, arr);
Everything works at least on Linux. Is this kosher, or am I using some
internal knowledge?
Here is the ABI spec:
https://dlang.org/spec/abi.html
One of the DConf Online 2020 slides thanks you! ;)
Ali
Re: Compiler is calling `_memset64` in betterC
On Monday, 19 October 2020 at 14:07:38 UTC, matheus wrote: On Sunday, 18 October 2020 at 19:24:28 UTC, Ferhat Kurtulmuş wrote: I plan to start a project in reasonable size, I wonder if I should really use betterC... if I encounter a bug like this, will I be stuck at it? The bug report says, it is a dmd specific problem, and LDC, my favorite d compiler, works well (tried it). So the "first party" compiler has a bug while the "third party" one works. That's weird. I would expect the other way around. Matheus. Ldc is used and tested more. An answer to this thread explains the situation. From: https://stackoverflow.com/questions/62265658/undefined-reference-to-memset64-when-creating-a-struct-array-under-dmd-with?r=SearchResults "I would highly recommend that you do not use DMD and instead stick to either LDC or GDC. They have far more tested and performant code generator, and have support for many more platforms. The debug info they generate will also be much better, and they have support for your use case (bare metal). – Geod24 Jun 10 at 3:30"
Re: Compiler is calling `_memset64` in betterC
On Monday, 19 October 2020 at 14:07:38 UTC, matheus wrote: On Sunday, 18 October 2020 at 19:24:28 UTC, Ferhat Kurtulmuş wrote: I plan to start a project in reasonable size, I wonder if I should really use betterC... if I encounter a bug like this, will I be stuck at it? The bug report says, it is a dmd specific problem, and LDC, my favorite d compiler, works well (tried it). So the "first party" compiler has a bug while the "third party" one works. That's weird. I would expect the other way around. Matheus. This is more or less the norm for backend issues in D. The ldc and gdc backends are shared with clang and gcc, so they are very well-maintained and bugs in them tend to get fixed quickly. The dmd backend, on the other hand, is maintained by only a small handful of people.
Re: Compiler is calling `_memset64` in betterC
On Sunday, 18 October 2020 at 19:24:28 UTC, Ferhat Kurtulmuş wrote: I plan to start a project in reasonable size, I wonder if I should really use betterC... if I encounter a bug like this, will I be stuck at it? The bug report says, it is a dmd specific problem, and LDC, my favorite d compiler, works well (tried it). So the "first party" compiler has a bug while the "third party" one works. That's weird. I would expect the other way around. Matheus.
Re: Undefined references in Druntime for microcontrollers
On Monday, 19 October 2020 at 06:25:17 UTC, Severin Teona wrote: Could you help me by telling me what libraries (and how) should I statically compile and link to the druntime? The microcontroller's CPU is an ARM Cortex-M4, and the libraries should be able to be compiled for this architecture. Thank you so much! Most probably they should be provided by your RTOS. At least, FreeRTOS have project for implement Posix thread calls.
Re: Undefined references in Druntime for microcontrollers
On Monday, 19 October 2020 at 06:25:17 UTC, Severin Teona wrote: - 'munmap' - 'clock_gettime' - `pthread_mutex_trylock' etc. These are typically calls found in a Unix system, Linux for example. In a microcontroller you will likely not support these at all except clock_gettime. You need to dissect druntime a bit further to remove these and/or find a replacement that does the same thing.
Re: D function in a .d file calling printf refuses to link.
On Sunday, 18 October 2020 at 21:44:10 UTC, WhatMeWorry wrote:
module mydll;
extern (C):
import core.stdc.stdio : printf;
export
{
int addSeven(int a, int b)
{
//printf("Hello from within my DLL");
return a+b+7;
}
}
The above D code file compiles and links, no problems with
C:\D\dmd2\samples\d\mydll>dmd -v -m64 mydll.d -L/DLL -L/NOENTRY
But as soon as I uncomment the printf, all hell breaks loose
with
legacy_stdio_definitions.lib(legacy_stdio_definitions.obj) :
error LNK2019: unresolved external symbol __acrt_iob_func
referenced in function _vwprintf_l
legacy_stdio_definitions.lib(legacy_stdio_definitions.obj) :
error LNK2019: unresolved external symbol
__stdio_common_vfwprintf referenced in function _vfwprintf_l
legacy_stdio_definitions.lib(legacy_stdio_definitions.obj) :
error LNK2019: unresolved external symbol
__stdio_common_vfwprintf_s referenced in function _vfwprintf_s_l
o o o
Walter Bright even wrote a three line module at
https://github.com/dlang/dmd/blob/master/samples/mydll/mydll.d
which uses the printf.
It appears as you use recent Microsoft Linker and toolset. Which
requires adding legacy_stdio_definitions.lib in linking list.
Also i tested this example with DMD 2.092.1 - completed
succesfully. It uses mingw toolset and lld-link. (I have no VS
installed)
Undefined references in Druntime for microcontrollers
Hi guys, I have been trying to port the current druntime for microcontrollers (that very little RAM and flash memory). I have been using the 'ldc-build-runtime' tool and finally I managed to compile something that looks alright. The problem is that I compiled the druntime with the flag 'BUILD_SHARED_LIBS=OFF' (as the microcontrollers don't work with dynamic libraries), and when I try to link the druntime with the application for the microcontroller, I get many errors about undefined references (references that would normally be present in those dynamic libraries). Few of them are: - 'munmap' - 'clock_gettime' - `pthread_mutex_trylock' etc. Could you help me by telling me what libraries (and how) should I statically compile and link to the druntime? The microcontroller's CPU is an ARM Cortex-M4, and the libraries should be able to be compiled for this architecture. Thank you so much!
