Hitchikers Guide to Porting Phobos / D Runtime to other architectures

[Joakim]

On Monday, 9 April 2012 at 09:05:25 UTC, Johannes Pfau wrote:
> Am Sun, 08 Apr 2012 21:08:52 +0200
> schrieb "Iain Buclaw" <ibuclaw at ubuntu.com>:
>
>> I got asked whether there are any porting hints for phobos on 
>> other architectures the other day from the debian GCC 
>> maintainers.  So I gathered this must be at least a dedicated 
>> wiki or article to be written up on the subject. :)
>> 
>> I know there are a few working on porting gdc and associated 
>> libraries over to ARM (with my assistance from the compiler 
>> side).  So please tell, what are your experiences? Successes?  
>> Failures?  What tips would you give to someone wanting to port 
>> to their own architecture?
>> 
>> Regards
>> Iain
>
> (This is mostly about porting to a different C library. I don't
> remember many issues when porting to a different CPU 
> architecture)
>
> Issues I hit with druntime:
>
> * Adapting the core.stdc bindings to something different than 
> the
>   currently supported C libraries sucks: The version blocks are
>   sometimes completely wrong. For example Android's bionic is a 
> C
>   library based on BSD code, but running on Linux. As a result
>   sometimes the version(FreeBSD) blocks apply for bionic, but 
> sometimes
>   the version(linux) blocks are right. I basically had to 
> rewrite
>   the complete core.stdc bindings. This is an issue because 
> druntime
>   and phobos do not distinguish between OS/Kernel and C library.
>
> * Wrong constants or macros in the C bindings are very hard to 
> spot -
>   you'll only notice those at runtime
>
> * When statically linking the phobos/druntime library you are 
> no warned
>   about missing symbols - For shared libraries  
> -Wl,--no-undefined can
>   be used, however, there are some issues with that as well:
>   
> (http://stackoverflow.com/questions/2356168/force-gcc-to-notify-about-undefined-references-in-shared-libraries
>   second answer)
>
> * Bionic just implements some functions as macros and never 
> exports
>   those as functions (htons, etc). Because of the last point 
> it's easy
>   to miss that
>
> Ideally all of the core.stdc bindings should be generated
> automatically. This is possible if we can run code (using 
> offsetof,
> alignof, etc) but it's not that easy for cross compilation. I 
> thought
> about hooking into the GCC C frontend to do that, but I had no 
> time to
> look at it yet.
>
> * All those issues also apply to phobos, where phobos uses 
> custom C
>   bindings / extern(C) declarations.
>
> * I had to edit some stuff in std.stdio (because Android has no 
> wide
>   character/fwide support). Templates can be annoying in this 
> case:
>   some if(isOutputRange!T) chains hid an error in the IO code, 
> it took
>   me some time to find that problem. The reported error was 
> completely
>   misleading (cannot put dchar[] into LockingTextWriter or 
> something)
>
> * When adding new, system specific code to a module and using 
> selective
>   imports, that may affect other modules (can't remember which 
> compiler
>   bug this was). This means that adding an import in one module 
> might
>   break another module on another architecture.
>
> * Porting the GC doesn't seem to be too difficult, but some 
> care is
>   needed to get stack scanning/TLS scanning right (If you have 
> random
>   crashes, it's either the GC not working(probably not scanning
>   stack/tls) or fno-section-anchors missing)
>
> * Always use "-fno-section-anchors". It's not needed for simple 
> code,
>   but I was chasing a weird bug in derelict, till I realized I 
> didn't
>   compile derelict with "-fno-section-anchors".
>
> * Right now, issue 284 is a little annoying. At least unittest 
> and
>   phobos/druntime as shared libraries won't work at all till 
> that's
>   fixed.
>
> * AFAIK the unittests cannot be run when cross-compiling right 
> now?
>
> * There might be more issues like this one where phobos is 
> checking for
>   a wrong status code:
>   (https://github.com/D-Programming-Language/phobos/pull/487)
>
> * For systems where long double isn't available, fixing 
> core.stdc.math
>   is annoying. I have to implement a proper solution which works
>   for all systems without long double.
>
> However, all that considered most issues are when interfacing 
> C. The D
> code most of the time 'just works'.
Seems like you got pretty far with your Android port: are you 
planning on submitting any of these patches back upstream?