Thank you Norman for your statement.
As it turned out, it not only requires binutils 2.24 but also gcc 4.9 in order to get appropriate LEON3 support. Fortunately, we're talking about a couple of small changes to the Sparc-specifc code that make this big difference.
I therefore went for the backporting option and can compile an elfimage for the LEON3 now. It doesn't bootstrap though but I think this can be solved rather quickly by a short debugging session. I stopped at this point because I had to schedule some other tasks but I will certainly revisit this issue.
For the curious ones: All the changes so far can be found in the repositories mentioned before.
Cheers Johannes
On Tue, 12 Aug 2014 10:40:15 +0200 Norman Feske <norman.feske@...1...> wrote:
Hi Johannes,
binutils 2.22 doesn't fully support LEON3 (missing CAS instruction). I therefore did a quick attempt of bumping the version numbers in the script to binutils 2.24 and gcc 4.8.2, which however fails with undefined type uint64_t errors in libstdc++v3.
why not updating binutils to version 2.22 but keep the current version of GCC? As far es I know, binutils and GCC are pretty well decoupled.
I think there are basically three options for me:
- Figure out how to compile the tool chain with the newer versions
of binutils and gcc, which may, however, have uncertain effects on Genode (?).
We are planning to upgrade the tool chain for the 14.11 release. So your effort would be well-spent. :-)
- Backport the missing LEON3 features to the versions currently
used for the Genode tool chain.
I would not recommend to go this route. You would need to dive right into the inner guts of the tool chain, which is not easy. Also your work will become obsolete once the tool chain gets updated the next time.
- Somehow work around the libc issues with the gaisler tool chain
(if possible at all).
I am afraid that this approach would open a new can of worms. Please revisit the rationale behind our tool chain [1].
[1] http://genode.org/download/tool-chain#Background_information_-_Why_do_we_nee...
In short, existing tool chains are either missing proper C++ support (so-called bare-metal tool chains) or expect a specific OS environment (i.e., glibc on Linux). The former variant does not suffice for compiling Genode because support libraries like libsupc++ are not shipped with them. The latter type (as apparently the gaisler tool chain) presumes certain properties from the environment (e.g., the way how TLS is handled) and a complete C runtime. Both conditions are not met by Genode's low-level environment. Genode's tool chain is a bare-metal tool chain with complete C++ support, but stripped from the dependency from a complete C runtime.
Do you have any comments on this? I guess I'd go for the second option unless you have any other suggestions.
I recommend to first just update binutils but keep the current GCC version. If this does not work, it would be sensible to upgrade the tool chain altogether. We would happily lend a helping hand with that.
Cheers Norman