www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC with MSP430

reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
Hello,

In the past I used LDC for bare metal programming of a RISC-V, 
simply by tweaking the white list of accepted architectures. I 
tried to do the same for the MSP430, but in this case it seems 
some other things will have to be tweaked. This might be 
something easy for someone more familiar with the LDC/LLVM 
codebase, so could anyone give a helping hand here?

The issue so far seems to be that LDC gets confused about the 
data type sizes, probably because the MSP430 has a 16-bit CPU 
core (C ints are 16 bit):

```
Assertion failed: (llSize <= dSize && "LLVM type is bigger than 
the corresponding D type, " "might lead to aggregate layout 
mismatch."), function getMemberSize, file ../gen/llvmhelpers.cpp, 
line 1351.
0  ldc2                     0x00000001034bbc9c 
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
1  ldc2                     0x00000001034bc1e9 
PrintStackTraceSignalHandler(void*) + 25
2  ldc2                     0x00000001034b8139 
llvm::sys::RunSignalHandlers() + 425
3  ldc2                     0x00000001034bc642 SignalHandler(int) 
+ 354
4  libsystem_platform.dylib 0x00007fffcee36b3a _sigtramp + 26
5  ldc2                     0x000000010396ce00 cppmain(int, 
char**)::DL + 48
6  libsystem_c.dylib        0x00007fffcecbb420 abort + 129
7  libsystem_c.dylib        0x00007fffcec82893 basename_r + 0
8  ldc2                     0x000000010145dbbf 
getMemberSize(Type*) + 175
9  ldc2                     0x000000010154ddc8 
AggrTypeBuilder::addAggregate(AggregateDeclaration*, 
std::__1::map<VarDeclaration*, llvm::Constant*, 
std::__1::less<VarDeclaration*>, 
std::__1::allocator<std::__1::pair<VarDeclaration* const, 
llvm::Constant*> > > const*, AggrTypeBuilder::Aliases) + 2824
10 ldc2                     0x000000010154d2b6 
AggrTypeBuilder::addAggregate(AggregateDeclaration*) + 38
11 ldc2                     0x000000010155199e 
IrTypeClass::addClassData(AggrTypeBuilder&, ClassDeclaration*) + 
414
12 ldc2                     0x00000001015520f4 
IrTypeClass::get(ClassDeclaration*) + 612
13 ldc2                     0x000000010150ae3e DtoType(Type*) + 
958
14 ldc2                     0x0000000101549d0e 
IrFuncTyArg::IrFuncTyArg(Type*, bool, AttrBuilder) + 126
15 ldc2                     0x0000000101549dbc 
IrFuncTyArg::IrFuncTyArg(Type*, bool, AttrBuilder) + 44
16 ldc2                     0x000000010143eb3c 
DtoFunctionType(Type*, IrFuncTy&, Type*, Type*, bool, bool, bool, 
bool) + 3468
17 ldc2                     0x00000001015552ac 
IrTypeFunction::get(Type*) + 220
18 ldc2                     0x000000010150ae6e DtoType(Type*) + 
1006
19 ldc2                     0x00000001014c6ce5 
createFwdDecl(LINK, Type*, llvm::ArrayRef<llvm::StringRef>, 
llvm::ArrayRef<Type*>, llvm::ArrayRef<unsigned long>, AttrSet) + 
373
20 ldc2                     0x00000001014b708f 
buildRuntimeModule() + 9327
21 ldc2                     0x00000001014b4c02 initRuntime() + 50
22 ldc2                     0x0000000101473178 
codegenModule(IRState*, Module*) + 248
23 ldc2                     0x000000010158a3ac 
ldc::CodeGenerator::emit(Module*) + 300
24 ldc2                     0x00000001015d8e4e 
codegenModules(Array<Module*>&) + 574
25 ldc2                     0x00000001012949c0 
mars_mainBody(Array<char const*>&, Array<char const*>&) + 5120
```

(BTW, I used -mtriple=msp430, since `msp430-gcc -dumpmachine` 
gives out that "triple")
Jun 19
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 20 June 2017 at 01:51:14 UTC, Luís Marques wrote:
 Hello,

 In the past I used LDC for bare metal programming of a RISC-V, 
 simply by tweaking the white list of accepted architectures. I 
 tried to do the same for the MSP430, but in this case it seems 
 some other things will have to be tweaked. This might be 
 something easy for someone more familiar with the LDC/LLVM 
 codebase, so could anyone give a helping hand here?

 The issue so far seems to be that LDC gets confused about the 
 data type sizes, probably because the MSP430 has a 16-bit CPU 
 core (C ints are 16 bit):

 ```
 Assertion failed: (llSize <= dSize && "LLVM type is bigger than 
 the corresponding D type, " "might lead to aggregate layout 
 mismatch."), function getMemberSize, file 
 ../gen/llvmhelpers.cpp, line 1351.
 0  ldc2                     0x00000001034bbc9c 
 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
 1  ldc2                     0x00000001034bc1e9 
 PrintStackTraceSignalHandler(void*) + 25
 2  ldc2                     0x00000001034b8139 
 llvm::sys::RunSignalHandlers() + 425
 3  ldc2                     0x00000001034bc642 
 SignalHandler(int) + 354
 4  libsystem_platform.dylib 0x00007fffcee36b3a _sigtramp + 26
 5  ldc2                     0x000000010396ce00 cppmain(int, 
 char**)::DL + 48
 6  libsystem_c.dylib        0x00007fffcecbb420 abort + 129
 7  libsystem_c.dylib        0x00007fffcec82893 basename_r + 0
 8  ldc2                     0x000000010145dbbf 
 getMemberSize(Type*) + 175
 9  ldc2                     0x000000010154ddc8 
 AggrTypeBuilder::addAggregate(AggregateDeclaration*, 
 std::__1::map<VarDeclaration*, llvm::Constant*, 
 std::__1::less<VarDeclaration*>, 
 std::__1::allocator<std::__1::pair<VarDeclaration* const, 
 llvm::Constant*> > > const*, AggrTypeBuilder::Aliases) + 2824
 10 ldc2                     0x000000010154d2b6 
 AggrTypeBuilder::addAggregate(AggregateDeclaration*) + 38
 11 ldc2                     0x000000010155199e 
 IrTypeClass::addClassData(AggrTypeBuilder&, ClassDeclaration*) 
 + 414
 12 ldc2                     0x00000001015520f4 
 IrTypeClass::get(ClassDeclaration*) + 612
 13 ldc2                     0x000000010150ae3e DtoType(Type*) + 
 958
 14 ldc2                     0x0000000101549d0e 
 IrFuncTyArg::IrFuncTyArg(Type*, bool, AttrBuilder) + 126
 15 ldc2                     0x0000000101549dbc 
 IrFuncTyArg::IrFuncTyArg(Type*, bool, AttrBuilder) + 44
 16 ldc2                     0x000000010143eb3c 
 DtoFunctionType(Type*, IrFuncTy&, Type*, Type*, bool, bool, 
 bool, bool) + 3468
 17 ldc2                     0x00000001015552ac 
 IrTypeFunction::get(Type*) + 220
 18 ldc2                     0x000000010150ae6e DtoType(Type*) + 
 1006
 19 ldc2                     0x00000001014c6ce5 
 createFwdDecl(LINK, Type*, llvm::ArrayRef<llvm::StringRef>, 
 llvm::ArrayRef<Type*>, llvm::ArrayRef<unsigned long>, AttrSet) 
 + 373
 20 ldc2                     0x00000001014b708f 
 buildRuntimeModule() + 9327
 21 ldc2                     0x00000001014b4c02 initRuntime() + 
 50
 22 ldc2                     0x0000000101473178 
 codegenModule(IRState*, Module*) + 248
 23 ldc2                     0x000000010158a3ac 
 ldc::CodeGenerator::emit(Module*) + 300
 24 ldc2                     0x00000001015d8e4e 
 codegenModules(Array<Module*>&) + 574
 25 ldc2                     0x00000001012949c0 
 mars_mainBody(Array<char const*>&, Array<char const*>&) + 5120
 ```

 (BTW, I used -mtriple=msp430, since `msp430-gcc -dumpmachine` 
 gives out that "triple")
What data layout is being used? Can you get clang to `-emit-llvm` and look at the resulting file 2nd line? should look like target datalayout = "..." .Please post the ... also please also compile with `-vv` and post the last section of diagnostics printed (warning it spits out a lot), the length of the backtrace should suffice. Nic
Jun 19
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 20 June 2017 at 06:52:05 UTC, Nicholas Wilson wrote:
 What data layout is being used? Can you get clang to 
 `-emit-llvm` and look at the resulting file 2nd line?

 should look like target datalayout = "..." .Please post the ...
I was going to say that I hadn't built clang, only LLVM, but that you could find that info in the target: LLVMTargetMachine(T, "e-m:e-p:16:16-i32:16:32-a:16-n8:16", TT, CPU, FS, Options, getEffectiveRelocModel(RM), CM, OL), ...but I want to help and I was not 100% sure that was what you wanted, so I went the extra mile ;) target datalayout = "e-m:e-p:16:16-i32:16:32-a:16-n8:16"
  also please also compile with `-vv` and post the last section 
 of diagnostics printed (warning it spits out a lot), the length 
 of the backtrace should suffice.
This is the full output for an empty .d file: $ ldc2 -mtriple=msp430 -c -betterC test.d -vv Targeting 'msp430' (CPU '' with features '') WARNING: Unknown ABI, guessing... Building type: real Building type: uint CodeGenerator::emit(test) * resetting 978 Dsymbols * *** Initializing D runtime declarations *** * * building runtime module * * Building type: extern (C) void(void*, void*) * * * DtoFunctionType(extern (C) void(void*, void*)) * * * * Building type: void * * * * Building type: void* * * * * Final function type: void (i8*, i8*) * * Building type: extern (C) void(char[], uint) * * * DtoFunctionType(extern (C) void(char[], uint)) * * * * Building type: char[] * * * * * Building type: char * * * * Final function type: void ({ i32, i8* }, i32) * * Building type: extern (C) void(char[], char[], uint) * * * DtoFunctionType(extern (C) void(char[], char[], uint)) * * * * Final function type: void ({ i32, i8* }, { i32, i8* }, i32) * * Building type: extern (C) void(immutable ModuleInfo*, uint) * * * DtoFunctionType(extern (C) void(immutable ModuleInfo*, uint)) * * * * Building type: ModuleInfo* * * * * * Building type: ModuleInfo * * * * * * Building struct type object.ModuleInfo /path/to/ldc/runtime/druntime/src/object.d(1517) * * * * * * * Field priority for _flags: 1 * * * * * * * Field priority for _index: 1 * * * * * * * final struct type: %object.ModuleInfo = type { i32, i32 } * * * * Final function type: void (%object.ModuleInfo*, i32) * * Building type: extern (C) void*(uint) * * * DtoFunctionType(extern (C) void*(uint)) * * * * Final function type: i8* (i32) * * Building type: extern (C) void*(TypeInfo) * * * DtoFunctionType(extern (C) void*(TypeInfo)) * * * * Building type: object.TypeInfo * * * * * Building class type object.TypeInfo /path/to/ldc/runtime/druntime/src/object.d(242) * * * * * * Instance size: 4 * * * * * * class type: %object.TypeInfo = type { [18 x i8*]*, i8* } * * * * Final function type: i8* (%object.TypeInfo*) * * Building type: extern (C) void[](const TypeInfo, uint) * * * DtoFunctionType(extern (C) void[](const TypeInfo, uint)) * * * * Building type: void[] * * * * Final function type: { i32, i8* } (%object.TypeInfo*, i32) * * Building type: extern (C) void[](const TypeInfo, uint[]) * * * DtoFunctionType(extern (C) void[](const TypeInfo, uint[])) * * * * Building type: uint[] * * * * Final function type: { i32, i8* } (%object.TypeInfo*, { i32, i32* }) * * Building type: extern (C) void[](const TypeInfo, uint, void[]*) * * * DtoFunctionType(extern (C) void[](const TypeInfo, uint, void[]*)) * * * * Building type: void[]* * * * * Final function type: { i32, i8* } (%object.TypeInfo*, i32, { i32, i8* }*) * * Building type: extern (C) void[](const TypeInfo, ref void[], uint) * * * DtoFunctionType(extern (C) void[](const TypeInfo, ref void[], uint)) * * * * Final function type: { i32, i8* } (%object.TypeInfo*, { i32, i8* }*, i32) * * Building type: extern (C) void[](const TypeInfo, ref void[], void[]) * * * DtoFunctionType(extern (C) void[](const TypeInfo, ref void[], void[])) * * * * Final function type: { i32, i8* } (%object.TypeInfo*, { i32, i8* }*, { i32, i8* }) * * Building type: extern (C) void[](ref void[], dchar) * * * DtoFunctionType(extern (C) void[](ref void[], dchar)) * * * * Building type: dchar * * * * Final function type: { i32, i8* } ({ i32, i8* }*, i32) * * Building type: extern (C) void[](const TypeInfo, void[], void[]) * * * DtoFunctionType(extern (C) void[](const TypeInfo, void[], void[])) * * * * Final function type: { i32, i8* } (%object.TypeInfo*, { i32, i8* }, { i32, i8* }) * * Building type: extern (C) void[](const TypeInfo, void[][]) * * * DtoFunctionType(extern (C) void[](const TypeInfo, void[][])) * * * * Building type: void[][] * * * * Final function type: { i32, i8* } (%object.TypeInfo*, { i32, { i32, i8* }* }) * * Building type: extern (C) Object(const TypeInfo_Class) * * * DtoFunctionType(extern (C) Object(const TypeInfo_Class)) * * * * Building type: object.Object * * * * * Building class type object.Object /path/to/ldc/runtime/druntime/src/object.d(89) * * * * * * Instance size: 4 * * * * * * class type: %object.Object = type { [5 x i8*]*, i8* } * * * * Building type: object.TypeInfo_Class * * * * * Building class type object.TypeInfo_Class /path/to/ldc/runtime/druntime/src/object.d(961) * * * * * * Instance size: 40 * * * * * * Field priority for m_init: 1 * * * * * * Field priority for name: 1 * * * * * * Field priority for vtbl: 1 * * * * * * Field priority for interfaces: 1 * * * * * * Field priority for base: 1 * * * * * * Field priority for destructor: 1 * * * * * * Field priority for classInvariant: 1 * * * * * * Field priority for m_flags: 1 * * * * * * Field priority for deallocator: 1 * * * * * * Field priority for m_offTi: 1 * * * * * * Field priority for defaultConstructor: 1 * * * * * * Field priority for m_RTInfo: 1 * * * * * * Building type: byte[] * * * * * * * Building type: byte Assertion failed: (llSize <= dSize && "LLVM type is bigger than the corresponding D type, " "might lead to aggregate layout mismatch."), function getMemberSize, file ../gen/llvmhelpers.cpp, line 1351. 0 ldc2 0x0000000111936c9c llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60 1 ldc2 0x00000001119371e9 PrintStackTraceSignalHandler(void*) + 25 2 ldc2 0x0000000111933139 llvm::sys::RunSignalHandlers() + 425 3 ldc2 0x0000000111937642 SignalHandler(int) + 354 4 libsystem_platform.dylib 0x00007fffcee36b3a _sigtramp + 26 5 ldc2 0x0000000111de7e00 cppmain(int, char**)::DL + 48 6 libsystem_c.dylib 0x00007fffcecbb420 abort + 129 7 libsystem_c.dylib 0x00007fffcec82893 basename_r + 0 8 ldc2 0x000000010f8d8bbf getMemberSize(Type*) + 175 9 ldc2 0x000000010f9c8dc8 AggrTypeBuilder::addAggregate(AggregateDeclaration*, std::__1::map<VarDeclaration*, llvm::Constant*, std::__1::less<VarDeclaration*>, std::__1::allocator<std::__1::pair<VarDeclaration* const, llvm::Constant*> > > const*, AggrTypeBuilder::Aliases) + 2824 10 ldc2 0x000000010f9c82b6 AggrTypeBuilder::addAggregate(AggregateDeclaration*) + 38 11 ldc2 0x000000010f9cc99e IrTypeClass::addClassData(AggrTypeBuilder&, ClassDeclaration*) + 414 12 ldc2 0x000000010f9cd0f4 IrTypeClass::get(ClassDeclaration*) + 612 13 ldc2 0x000000010f985e3e DtoType(Type*) + 958 14 ldc2 0x000000010f9c4d0e IrFuncTyArg::IrFuncTyArg(Type*, bool, AttrBuilder) + 126 15 ldc2 0x000000010f9c4dbc IrFuncTyArg::IrFuncTyArg(Type*, bool, AttrBuilder) + 44 16 ldc2 0x000000010f8b9b3c DtoFunctionType(Type*, IrFuncTy&, Type*, Type*, bool, bool, bool, bool) + 3468 17 ldc2 0x000000010f9d02ac IrTypeFunction::get(Type*) + 220 18 ldc2 0x000000010f985e6e DtoType(Type*) + 1006 19 ldc2 0x000000010f941ce5 createFwdDecl(LINK, Type*, llvm::ArrayRef<llvm::StringRef>, llvm::ArrayRef<Type*>, llvm::ArrayRef<unsigned long>, AttrSet) + 373 20 ldc2 0x000000010f93208f buildRuntimeModule() + 9327 21 ldc2 0x000000010f92fc02 initRuntime() + 50 22 ldc2 0x000000010f8ee178 codegenModule(IRState*, Module*) + 248 23 ldc2 0x000000010fa053ac ldc::CodeGenerator::emit(Module*) + 300 24 ldc2 0x000000010fa53e4e codegenModules(Array<Module*>&) + 574 25 ldc2 0x000000010f70f9c0 mars_mainBody(Array<char const*>&, Array<char const*>&) + 5120
Jun 20
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 20 June 2017 at 08:59:05 UTC, Luís Marques wrote:
 On Tuesday, 20 June 2017 at 06:52:05 UTC, Nicholas Wilson wrote:
 What data layout is being used? Can you get clang to 
 `-emit-llvm` and look at the resulting file 2nd line?

 should look like target datalayout = "..." .Please post the ...
I was going to say that I hadn't built clang, only LLVM, but that you could find that info in the target: LLVMTargetMachine(T, "e-m:e-p:16:16-i32:16:32-a:16-n8:16", TT, CPU, FS, Options, getEffectiveRelocModel(RM), CM, OL), ...but I want to help and I was not 100% sure that was what you wanted, so I went the extra mile ;) target datalayout = "e-m:e-p:16:16-i32:16:32-a:16-n8:16"
  also please also compile with `-vv` and post the last section 
 of diagnostics printed (warning it spits out a lot), the 
 length of the backtrace should suffice.
This is the full output for an empty .d file: [...]
Hmm it strikes me as odd that it handles char[] fine but not byte[]. Might want to confirm the types and sizes involved by adding: Logger::cout() << "getMemberSize: D type " << type->toChars() << " ("<< dSize<<" bytes)" <<" LL type " << *llType <<"(" << llSize<< " bytes)\n"; (I hope I have that right to just copy & paste) between the call to gDataLayout->getTypeAllocSize(llType); and the assert on line 1348 of llvmhelpers.cpp
Jun 20
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 20 June 2017 at 10:52:14 UTC, Nicholas Wilson wrote:
 Might want to confirm the types and sizes involved by adding:

 Logger::cout() << "getMemberSize: D type " << type->toChars() 
 << " ("<< dSize<<" bytes)" <<" LL type " << *llType <<"(" << 
 llSize<< " bytes)\n";

 (I hope I have that right to just copy & paste) between the 
 call to

 gDataLayout->getTypeAllocSize(llType);

 and the assert on line 1348 of llvmhelpers.cpp
Yup, this isn't going to fly: * * * * * * getMemberSize: D type byte[] (4 bytes) LL type { i32, i8* }(6 bytes) According to msp430-gcc, #define __SIZEOF_SIZE_T__ 2, so it's the LLVM side that's wrong. Do you know where to change this?
Jun 20
next sibling parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 20 June 2017 at 15:08:26 UTC, Luís Marques wrote:
 Do you know where to change this?
Found it. tollvm.cpp:260: t = (global.params.isLP64) ? LLType::getInt64Ty(gIR->context()) : LLType::getInt32Ty(gIR->context());
Jun 20
prev sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Luís,

On 20 Jun 2017, at 16:08, Luís Marques via digitalmars-d-ldc wrote:
 According to msp430-gcc, #define __SIZEOF_SIZE_T__ 2, so it's the LLVM 
 side that's wrong.

 Do you know where to change this?
DtoSize_t() in gen/tollvm.cpp. However, note that there are currently no supported 16 bit targets (and indeed, only 32 bit and up is supported as per the D spec, although that doesn't mean it can't be usefully targeted in an embedded context), so there is a chance there are related bugs in other places. Best, David
Jun 20
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 20 June 2017 at 15:19:07 UTC, David Nadlinger wrote:
 However, note that there are currently no supported 16 bit 
 targets (and indeed, only 32 bit and up is supported as per the 
 D spec, although that doesn't mean it can't be usefully 
 targeted in an embedded context), so there is a chance there 
 are related bugs in other places.
Don't worry, I'll bug you guys ;-) BTW, what part of the D spec that isn't x86 specific clashes with 16 bit? Over the years I've seen people saying that D can't be used for <32 bits, but I don't remember seeing anything in the spec that was actually a problem. Now, if we were talking about weird type sizes (9-bit chars...) that would be different. FYI: My first quick test compiled fine (to assembly; I don't think the target supports object file generation; I have to finish assembly and linking with the gnu tools, like I did for RISC-V).
Jun 20
next sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Luís,

On 20 Jun 2017, at 16:29, Luís Marques via digitalmars-d-ldc wrote:
 BTW, what part of the D spec that isn't x86 specific clashes with 16 
 bit? Over the years I've seen people saying that D can't be used for 
 <32 bits, but I don't remember seeing anything in the spec that was 
 actually a problem. Now, if we were talking about weird type sizes 
 (9-bit chars...) that would be different.

 FYI: My first quick test compiled fine (to assembly; I don't think the 
 target supports object file generation; I have to finish assembly and 
 linking with the gnu tools, like I did for RISC-V).
It is more of a general statement of direction rather than any one thing that clashes with narrower architectures in particular (which, I agree, is confusing, but perhaps Walter didn't want to give the impression that DMD was on par with DMC when it comes to 16 bit DOS executables). Two things that are not supported are non-power-of-two address widths and non-flat pointer types (segmented memory, or different near/far pointer types). Some of the library artefacts like the GC also won't work well with such a small memory space. Best, David
Jun 23
prev sibling parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 20 June 2017 at 15:29:35 UTC, Luís Marques wrote:
 FYI: My first quick test compiled fine (to assembly; I don't 
 think the target supports object file generation; I have to 
 finish assembly and linking with the gnu tools, like I did for 
 RISC-V).
It seems that `clang --target=msp430 -c test.c` generates an object file successfully, while `ldc2 -O2 -mtriple=msp430 -c test.d` fails: ``` no support for asm output UNREACHABLE executed at ../driver/toobj.cpp:130! 0 ldc2 0x0000000107e19c9c llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60 1 ldc2 0x0000000107e1a1e9 PrintStackTraceSignalHandler(void*) + 25 2 ldc2 0x0000000107e16139 llvm::sys::RunSignalHandlers() + 425 3 ldc2 0x0000000107e1a642 SignalHandler(int) + 354 4 libsystem_platform.dylib 0x00007fffa0ad5b3a _sigtramp + 26 5 libsystem_platform.dylib 0x0000000000000003 _sigtramp + 1599251683 6 libsystem_c.dylib 0x00007fffa095a420 abort + 129 7 ldc2 0x0000000107d246c0 LLVMInstallFatalErrorHandler + 0 8 ldc2 0x0000000105efd2a7 codegenModule(llvm::TargetMachine&, llvm::Module&, llvm::raw_fd_ostream&, llvm::TargetMachine::CodeGenFileType) + 391 9 ldc2 0x0000000105f00ab9 (anonymous namespace)::writeObjectFile(llvm::Module*, char const*) + 377 10 ldc2 0x0000000105efcc05 writeModule(llvm::Module*, char const*) + 10517 11 ldc2 0x0000000105ee6162 ldc::CodeGenerator::writeAndFreeLLModule(char const*) + 1602 12 ldc2 0x0000000105ee6a82 ldc::CodeGenerator::finishLLModule(Module*) + 130 13 ldc2 0x0000000105ee880c ldc::CodeGenerator::emit(Module*) + 1420 14 ldc2 0x0000000105f36e4e codegenModules(Array<Module*>&) + 574 15 ldc2 0x0000000105bf2a00 mars_mainBody(Array<char const*>&, Array<char const*>&) + 5120 Abort trap: 6 ``` Curiously, if you do `clang --target=msp430 -S -emit-llvm test.c` and then you try to generate the object file from test.ll, llc fails: ``` llc -filetype=obj test.ll /opt/msp430/bin/llc: target does not support generation of this file type! ``` Any idea on how we can get LDC to generate object files directly?
Jul 05
parent reply Johan Engelen <j j.nl> writes:
On Wednesday, 5 July 2017 at 18:16:39 UTC, Luís Marques wrote:
 
 It seems that `clang --target=msp430 -c test.c` generates an 
 object file successfully, while `ldc2 -O2 -mtriple=msp430 -c 
 test.d` fails:
Perhaps it's good to verify that the clang and LDC triples are the same. Just the first thing that came to mind, Johan
Jul 05
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Wednesday, 5 July 2017 at 21:16:11 UTC, Johan Engelen wrote:
 Perhaps it's good to verify that the clang and LDC triples are 
 the same.
They are: source_filename = "test.d" target datalayout = "e-m:e-p:16:16-i32:16:32-a:16-n8:16" target triple = "msp430" source_filename = "test.c" target datalayout = "e-m:e-p:16:16-i32:16:32-a:16-n8:16" target triple = "msp430"
Jul 05
parent reply Johan Engelen <j j.nl> writes:
On Wednesday, 5 July 2017 at 22:13:36 UTC, Luís Marques wrote:
 On Wednesday, 5 July 2017 at 21:16:11 UTC, Johan Engelen wrote:
 Perhaps it's good to verify that the clang and LDC triples are 
 the same.
They are: source_filename = "test.d" target datalayout = "e-m:e-p:16:16-i32:16:32-a:16-n8:16" target triple = "msp430"
Hm, doesn't really look like a "triple" (3), but OK :-) Can you ask on the LLVM list about the `llc` failure? You may get a hint about how to make LDC behave the same as Clang on this point. Perhaps asking too much but, you could also try searching through Clang's codebase to see if there is any relevant special casing for the msp430 target. -Johan
Jul 05
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Wednesday, 5 July 2017 at 23:33:37 UTC, Johan Engelen wrote:
 Hm, doesn't really look like a "triple" (3), but OK :-)
It's probably equivalent to msp430-elf-unknown or something like that. Hey, these days the "triples" can have 4 parts so...
 Can you ask on the LLVM list about the `llc` failure? You may 
 get a hint about how to make LDC behave the same as Clang on 
 this point.

 Perhaps asking too much but, you could also try searching 
 through Clang's codebase to see if there is any relevant 
 special casing for the msp430 target.
OK.
Jul 05
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Wednesday, 5 July 2017 at 23:39:09 UTC, Luís Marques wrote:
 Can you ask on the LLVM list about the `llc` failure? You may 
 get a hint about how to make LDC behave the same as Clang on 
 this point.
Reply: "There is no direct object emission support in MSP430 backend. clang executed assembler under the hood." Should LDC also learn to do this?
Jul 05
next sibling parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Thursday, 6 July 2017 at 00:27:23 UTC, Luís Marques wrote:
 Should LDC also learn to do this?
Nicholas Wilson suggested -no-integrated-as in the LLVM mailing list, although it seems it doesn't quite work. But at least the flag is already there, and can be made default for MSP430 (maybe for all archs that don't have code generation?).
Jul 05
prev sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Luís,

On 6 Jul 2017, at 1:27, Luís Marques via digitalmars-d-ldc wrote:
 "There is no direct object emission support in MSP430 backend. clang
 executed assembler under the hood."

 Should LDC also learn to do this?
LDC also doesn't use an external assembler by default (see shouldAssembleExternally() in toobj.cpp). One way to track this down further would be to attach a debugger to LDC and see where it tries to access the MC assembler infrastructure (it shouldn't). Best, David
Jul 05
prev sibling parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 20 June 2017 at 01:51:14 UTC, Luís Marques wrote:
 In the past I used LDC for bare metal programming of a RISC-V, 
 simply by tweaking the white list of accepted architectures. I 
 tried to do the same for the MSP430, but in this case it seems 
 some other things will have to be tweaked. This might be 
 something easy for someone more familiar with the LDC/LLVM 
 codebase, so could anyone give a helping hand here?
BTW, is there a flag to avoid trying to build Phobos and druntime, since those fail with an unsupported target?
Jun 20
next sibling parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 20 June 2017 at 16:31:28 UTC, Luís Marques wrote:
 On Tuesday, 20 June 2017 at 01:51:14 UTC, Luís Marques wrote:
 In the past I used LDC for bare metal programming of a RISC-V, 
 simply by tweaking the white list of accepted architectures. I 
 tried to do the same for the MSP430, but in this case it seems 
 some other things will have to be tweaked. This might be 
 something easy for someone more familiar with the LDC/LLVM 
 codebase, so could anyone give a helping hand here?
BTW, is there a flag to avoid trying to build Phobos and druntime, since those fail with an unsupported target?
Not the answer you are looking for ("PRs welcome" ;-), but: does `make ldc2` do the trick? ;) Johan
Jun 20
parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Tuesday, 20 June 2017 at 16:59:03 UTC, Johan Engelen wrote:
 Not the answer you are looking for ("PRs welcome" ;-), but:
 does `make ldc2` do the trick?
That's perfectly fine, and it works. (I tried it only with `ninja ldc2`)
Jun 20
prev sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 20 Jun 2017, at 17:31, Luís Marques via digitalmars-d-ldc wrote:
 BTW, is there a flag to avoid trying to build Phobos and druntime, 
 since those fail with an unsupported target?
You can actually disable building Phobos by setting PHOBOS2_DIR to an empty string, but I believe the "all" target always includes druntime right now. As pointed out elsewhere in this thread, just building the "ldc2" target should work, though. — David
Jun 20