digitalmars.D.ldc - LDC with MSP430
- =?UTF-8?B?THXDrXM=?= Marques (74/74) Jun 19 2017 Hello,
- Nicholas Wilson (8/83) Jun 19 2017 What data layout is being used? Can you get clang to `-emit-llvm`
- =?UTF-8?B?THXDrXM=?= Marques (186/192) Jun 20 2017 I was going to say that I hadn't built clang, only LLVM, but that
- Nicholas Wilson (11/30) Jun 20 2017 Hmm it strikes me as odd that it handles char[] fine but not
- =?UTF-8?B?THXDrXM=?= Marques (7/15) Jun 20 2017 Yup, this isn't going to fly:
- =?UTF-8?B?THXDrXM=?= Marques (6/7) Jun 20 2017 Found it. tollvm.cpp:260:
- David Nadlinger via digitalmars-d-ldc (9/12) Jun 20 2017 DtoSize_t() in gen/tollvm.cpp.
- =?UTF-8?B?THXDrXM=?= Marques (11/16) Jun 20 2017 Don't worry, I'll bug you guys ;-)
- David Nadlinger via digitalmars-d-ldc (12/20) Jun 23 2017 It is more of a general statement of direction rather than any one thing...
- =?UTF-8?B?THXDrXM=?= Marques (49/53) Jul 05 2017 It seems that `clang --target=msp430 -c test.c` generates an
- Johan Engelen (5/9) Jul 05 2017 Perhaps it's good to verify that the clang and LDC triples are
- =?UTF-8?B?THXDrXM=?= Marques (8/10) Jul 05 2017 They are:
- Johan Engelen (9/16) Jul 05 2017 Hm, doesn't really look like a "triple" (3), but OK :-)
- =?UTF-8?B?THXDrXM=?= Marques (4/11) Jul 05 2017 It's probably equivalent to msp430-elf-unknown or something like
- =?UTF-8?B?THXDrXM=?= Marques (6/9) Jul 05 2017 Reply:
- =?UTF-8?B?THXDrXM=?= Marques (5/6) Jul 05 2017 Nicholas Wilson suggested -no-integrated-as in the LLVM mailing
- David Nadlinger via digitalmars-d-ldc (8/11) Jul 05 2017 LDC also doesn't use an external assembler by default (see
- =?UTF-8?B?THXDrXM=?= Marques (3/9) Jun 20 2017 BTW, is there a flag to avoid trying to build Phobos and
- Johan Engelen (5/14) Jun 20 2017 Not the answer you are looking for ("PRs welcome" ;-), but:
- =?UTF-8?B?THXDrXM=?= Marques (3/5) Jun 20 2017 That's perfectly fine, and it works. (I tried it only with `ninja
- David Nadlinger via digitalmars-d-ldc (7/9) Jun 20 2017 You can actually disable building Phobos by setting PHOBOS2_DIR to an
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 2017
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 2017
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 2017
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: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.cppWhat 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: [...]
Jun 20 2017
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 2017
=?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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: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. -JohanPerhaps 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"
Jul 05 2017
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 2017
On Wednesday, 5 July 2017 at 23:39:09 UTC, Luís Marques wrote:Reply: "There is no direct object emission support in MSP430 backend. clang executed assembler under the hood." Should LDC also learn to do this?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.
Jul 05 2017
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 2017
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 2017
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 2017
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:Not the answer you are looking for ("PRs welcome" ;-), but: does `make ldc2` do the trick? ;) JohanIn 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 2017
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 2017
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 2017