Add FreeBSD/aarch64 support #146
Conversation
There was a problem hiding this comment.
Have you tried running the druntime tests? ctest -R druntime-test-runner$; ./runtime/druntime-test-runner should show you what's working (check out the ldc-ltsmaster branch of druntime first and apply your patch there, so all the tests are run on a single invocation of the test runner).
src/core/sys/posix/setjmp.d
Outdated
| enum _JBLEN = 31; | ||
| // __int128_t | ||
| struct _jmp_buf { long[2][_JBLEN + 1] _jb; }; | ||
| } |
There was a problem hiding this comment.
Everything after the first file should go upstream at dlang/druntime, submit this there instead.
|
druntime tests fail at CTFE stage: (& same for many more of these conversions) After removing/commenting out these, build-druntime-test-runner passes and (I've been working on the revision referenced from ldc lts, looks like 1 commit behind |
|
All other tests in |
|
Use the patch from dlang#2257, that should fix the CTFE issue. Make sure you're on the Also, have you tried building LDC master and its druntime tests using ltsmaster? I'd like to know what happens then. |
|
(Haven't tried with patched ltsmaster yet) ldc master segfaulted when building phobos, with an entirely unhelpful core dump ( Actually, before I got to that point, there were weird initialization issues (things not being initialized) for which I made some questionable workarounds: --- i/dmd/identifier.d
+++ w/dmd/identifier.d
@@ -182,6 +182,7 @@ nothrow:
static Identifier idPool(const(char)* s, uint len)
{
+ initTable();
StringValue* sv = stringtable.update(s, len);
Identifier id = cast(Identifier)sv.ptrvalue;
if (!id)
@@ -240,6 +241,7 @@ nothrow:
static void initTable()
{
- stringtable._init(28000);
+ if (stringtable.table == null)
+ stringtable._init(28000);
}
}
--- i/dmd/root/stringtable.d
+++ w/dmd/root/stringtable.d
@@ -62,7 +62,6 @@ pure:
struct StringTable
{
private:
- StringEntry* table;
size_t tabledim;
ubyte** pools;
size_t npools;
@@ -70,6 +69,7 @@ private:
size_t count;
public:
+ StringEntry* table;
extern (C++) void _init(size_t size = 0) nothrow
{
size = nextpow2(cast(size_t)(size / loadFactor));--- i/gen/target.cpp
+++ w/gen/target.cpp
@@ -25,6 +25,7 @@
using llvm::APFloat;
void Target::_init() {
+ CTFloat::_init();
FloatProperties::_init();
DoubleProperties::_init();
RealProperties::_init(); |
|
Yeah, same issues on other AArch64 platforms with a natively-built LDC master, may want to try this new ltsmaster pull, ldc-developers/ldc#2811, to see what difference it makes. Regarding the DMD testsuite issues, how do the Phobos tests do first? |
Looks like I need to learn to actually read error messages! The CTFE error was Now only dmd tests fail (that |
|
See if you can bootstrap LDC master and its tests pass now with the latest version of ldc-developers/ldc#2811 applied, as I noted for other platforms. Submit all your non- Weird that you're getting |
|
The initialization bugs in ldc master are still there With the (bad) workarounds described above, I'm seeing super weird syntax errors that make zero sense, such as: (actually this was happening the last time as well, not segfault) This is probably related to |
|
Did you apply the changes to |
|
Oops I did not. Applying them results in an LLVM assertion failure: Looks like that assertion is still there even in current dev llvm. (currently building llvm without that assertion) |
|
Huh, guess it only worked for us since we used llvm with assertions disabled. |
|
The va_list thing with assertions disabled didn't change anything. The initialization failure is not vararg related, as I expected… |
|
I'm skeptical that you're having some other non- |
Yep, it almost certainly isn't. By the looks of it, the module ctors aren't run; this might also cause your [Changing a struct layout on one side only (D/C++), e.g., moving member |
|
Yeah, that's it: import core.stdc.stdio;
shared static this() { printf("shared static\n"); }
shared static ~this() { printf("~shared static\n"); }
static this() { printf("static\n"); }
static ~this() { printf("~static\n"); }
void main() { printf("main\n"); }(compiled with LTS) only prints "main". Stepping through |
|
So, there's no And there's Linking with |
|
Nice findings. Seems to be related to problems with |
|
Yeah, I'm seeing TLS related warnings with bfd too. Temporarily changed hmm — TLS is mentioned in the backtrace. |
|
The GC is running in your LDC? That doesn't make sense, LDC doesn't use the D GC internally. |
|
Seems like the GC isn't disabled early enough… |
|
So just to be sure, all the same tests pass for ltsmaster once you started using ld.bfd? Also, you never saw test failures there with You can remove the changes from this pull that were merged upstream, I will just cherry-pick that commit. |
|
Yeah, all the same tests pass on ltsmaster — only dmd fails. Never saw other failures. |
|
The GC segfault above indicates invalid TLS ranges, which might depend on the linker again.
Yep indeed, but that looks like an upstream issue. https://github.com/ldc-developers/ldc/blob/master/dmd/imphint.d#L34-L43 leads to a |
|
Since bfd has emitted TLS warnings, it certainly might have screwed this up. I need to get LLD working (fix the section groups thing), but I don't really know what to look for. Can I do something with objdump/readelf to compare the binaries made by different linkers? |
|
Not so sure about the TLS warnings; I quickly looked them up, and they are apparently safe to discard (and should be fixed with clang 7).
Sure. Use something minimal (with @llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @void onlineapp.init(), i8* null }] ; [#uses = 0]Then check the asm of the object file, where you should find an .section .init_array,"aw",@init_array
.p2align 3
.xword void onlineapp.init() ; run.dlang.io automatically demangles...Then finally compare the bfd/lld-linked binaries, sections, symbols etc. There might be missing (linker-magic) symbols bracketing a section and whatnot. |
|
Looks like ltsmaster doesn't support The various symbols with "moduleinfo" in the name don't seem to look different… |
|
I was just looking into this: no |
|
I rather think it's wrongly stripping them out ( |
heh — that's what I just started doing… but wasn't aware of |
|
As already mentioned, that |
|
What I mean is that ltsmaster predates generating a Update: Never mind, I now see it was using explicitly generated |
I don't think that's used, sections_elf_shared.d is there and supports FreeBSD |
[That file isn't used for Linux and FreeBSD (it really just seems to be used as fallback for unknown OS), |
I can only find relocation-related issues for that…
The default linker is lld 6. I also tried 5.0 and lld-devel (7.0.d20180523), same results. bfd is from binutils-2.30.
I'm not sure where 60 would come from? @llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @ldc.dso_ctor.10testconstr, i8* null }] ; [#uses = 0] |
druntime (+ C libs possibly). There's one ctor/dtor per (linked-in) D object file. 60 ctors also more or less match the 59 (0x1d8 / 8) ModuleInfos. |
valpackett
force-pushed
the
freebsd-aarch64
branch
from
d52a955
to
791a801
Compare
|
Huh, new FreeBSD commit: https://reviews.freebsd.org/D17587 "Implement a BSD licensed crtbegin/crtend" "These are needed for .ctors/.dtors and .jcr handling" "Perhaps put a comment here that arm64 does not use .ctors/.dtors or such?" I'll ask about this… UPD: facepalm, we were already talking about |
|
So looks like the object file from the compiler has the ctors as And why are there |
|
So the GC issue is still present (when linking with lld). |
|
Just with LLD? |
|
bfd too (you can see above, I first discovered it with bfd, thought it might be bfd's fault, but no) |
|
I suspect a FreeBSD-specific problem in I'd suggest using |
|
I hope that this problem was fixed by https://svnweb.freebsd.org/changeset/base/341512 But 'rust' itself needs additional patch, which is currently in review state. I hope that I will be able to commit it in next few days. (Bulk ports compile is still in progress to verify this patch, RTLD TLS handling is complicated from time to time). |
|
Yes, looks like this was the same problem that was screwing up Rust. I'm not sure if D18417 is necessary for LDC or r341512 is enough, but I'm on a kernel with D18417 applied currently. Thanks @strejda! Now I have built ldc2, tests are mostly running out of memory (because I built ldc2 in debug mode :D), building dub failed with Sooooo the changes I have in my repos are:
UPD: backtrace isn't actually working, I'm probably writing into the variable and not to where the variable points to, trying that fix. But why aren't we using libbacktrace?… |
|
The |
|
valpackett
force-pushed
the
freebsd-aarch64
branch
from
791a801
to
0802f36
Compare
|
Backtrace works now, thanks! Updated this PR. |
|
I've also cherry-picked it to ltsmaster. - The other patches you cherry-picked for ltsmaster aren't required to build it and then use it for building master, right? They aren't for Linux/AArch64 and don't seem FreeBSD specific (dlang@ce863ec shouldn't be an issue, as LDC itself is usually linked against static druntime). |
|
coming back to this:
and with that, we can build it in Ports for packaging :) |
I hope this is correct… This makes the 0.17 bootstrap compiler work, at least.