On Fri, 22 Sep 2017, Paulo Matos wrote:
> > Note that even without a simulator (but with target libc), you can test
> > just the compilation parts of the testsuite using a board file with a
> > dummy <board>_load implementation.
> >
>
> I was not aware of that. I will keep that in mind once I try to setup a
> cross-compilation worker.
>
> I assume you have done this before. Do you have any scripts for
> cross-compiling you can share?
Here is a board file (by Janis Johnson) that stubs out test execution (you
still need to be able to link, and for some bare-metal configurations
linking may not work by default without specifying a linker script that
chooses a BSP).
load_generic_config "sim"
set_board_info hostname "dummy-run"
set board_info(localhost,isremote) 0
process_multilib_options ""
# Override ${target}_load to do nothing.
foreach t $target_list {
proc ${t}_load { args } {
send_user "dummy load does nothing\n"
return [list "unresolved" ""]
}
}
glibc's build-many-glibcs.py shows the preferred modern approach for
bootstrapping a cross toolchain for a target using glibc. (However, the
set of configurations it builds aims at covering glibc configuration
space, especially as regards ABIs, and is probably more than is relevant
for testing GCC for those architectures.) Tools such as crosstool-ng have
recipes for building cross toolchains that may also be useful to look at,
but many such tools often do things for glibc builds that haven't been
necessary for several years.
For bare metal you'll want newlib instead of glibc (configure that with
the same --build --host --target as GCC, since it's the same top-level
build system, and that build system deals internally with making "host"
for configuring the newlib subdirectory the same as "target" was at top
level).
--
Joseph S. Myers
jos...@codesourcery.com
