Hey guys,
I'm trying to add a new architecture, namely the LEON3, to Genode.
Some time ago, I already added rudimentary LEON3 support to Fiasco.OC. Thus I thought it shouldn't take too much of an effort to get this working with Genode on top of it.
The LEON3 port for Fiasco.OC was based on the l4re snapshot from April 2013. I therefore (back)ported the implementation to Genode's foc clone. You can find the code at github [1] (beware, it's not tested yet).
I also added the foc_leon3 build target along with the required platform-specific code to Genode [2].
Unfortunately, I got stuck a little at this point. I.e. when I run e.g. 'make run/printf' for this target, I get a couple of linker errors that I cannot relate to anything in the Genode source code, e.g.:
repos/os/src/init/main.cc:178: undefined reference to `atexit'
`.text.__sparc_get_pc_thunk.l7' referenced in section `.text' of /build/foc_leon3/var/libcache/cxx/cxx.lib.a(supc++.o): defined in discarded section `.text.__sparc_get_pc_thunk.l7[__sparc_get_pc_thunk.l7]' of build/foc_leon3/var/libcache/cxx/cxx.lib.a(supc++.o)
build/foc_leon3/var/libcache/cxx/cxx.lib.a(supc++.o): In function `__gnu_cxx::__verbose_terminate_handler()': (.text+0x31cc): undefined reference to `_impure_ptr'
I assume these errors might be related to the tool chain but this is a rather wild guess. Do you have any (more educated) suggestions?
I'm using the dev version of the bare-c compiler provided by gaisler [3] which bases on gcc 4.6.0. Of course, this is not an optimal solution but the best I could achieve so far.
[1] https://github.com/ValiValpas/foc/tree/leon3 [2] https://github.com/ValiValpas/genode/tree/leon3 [3] http://developer.gaisler.net/download/bcc/linux/4.6.0/
Cheers Johannes
Hello Johannes,
We walked a long rocky road with third-party tool chains until we decided to go for our own. The main reason for issues with other tools was the lacking support for C++ without a full fledged libC runtime.
You may find our tool-chain script in tool/tool_chain, which officially supports x86 and arm. There are also traces of support for microblaze, but we did not test it years. Maybe you can add LEON3 to the script and get rid of those undefined references to libC symbols we do not provide in our runtime.
Regards
Christian,
thanks for your reply. Unfortunately, adding LEON3 support to the tool_chain script is not that easy.
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.
I think there are basically three options for me:
1. Figure out how to compile the tool chain with the newer versions of binutils and gcc, which may, however, have uncertain effects on Genode (?). 2. Backport the missing LEON3 features to the versions currently used for the Genode tool chain. 3. Somehow work around the libc issues with the gaisler tool chain (if possible at all).
Do you have any comments on this? I guess I'd go for the second option unless you have any other suggestions.
Regards Johannes
On Tue, 5 Aug 2014 09:52:11 +0200 Christian Helmuth <christian.helmuth@...1...> wrote:
Hello Johannes,
We walked a long rocky road with third-party tool chains until we decided to go for our own. The main reason for issues with other tools was the lacking support for C++ without a full fledged libC runtime.
You may find our tool-chain script in tool/tool_chain, which officially supports x86 and arm. There are also traces of support for microblaze, but we did not test it years. Maybe you can add LEON3 to the script and get rid of those undefined references to libC symbols we do not provide in our runtime.
Regards
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
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
-
Christian Helmuth -
Johannes Schlatow -
Norman Feske