While looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018, I noticed that $ aarch64-none-elf-gcc conftest.c -o conftest fails to link unless one uses --specs=rdimon.specs. Otherwise, newlib's crt0.S reference to initialise_monitor_handles and exit.o reference to _exit cannot be resolved. the arm-none-eabi compiler does not need such an option. Is this on purpose, or is this a bug? If on purpose, it looks like GCC build for aarch64-none-elf should set LDFLAGS_FOR_TARGET=--specs=rdimon.specs.
This is more an arm newlib bug than a gcc aarch64 bug. Most embedded ports support more than one rom monitor. libgloss provides more than one set of start files and libraries for these different rom monitors. Users are expected to supply a --specs option when linking to choose the right support files for the rom monitor in use. This is how the aarch64 port works. However, arm works differently. There is a single set of start files and libraries provided by newlib that override libgloss. These are compiled for rdimon. If you want to compile for a different rom monitor, then you either need to add a newlib configure option --disable-newlib-supplied-syscalls or else you need to hand edit newlib/libc/configure.host to enable a different choice. This was probably done to make this easier for end users. If you make one rom monitor the default, then they don't have to read docs to figure out how to link. Though this also means that by default the support for the other rom monitors is broken unless you rebuild the toolchain. This probably hasn't been done for aarch64 yet simply because there aren't enough people doing bare target work for aarch64, and hence people haven't yet noticed that the arm and aarch64 ports are working differently. I do see a number of problems with the arm support here though. There are two copies of the syscalls.c file, one in newlib/libc/sys/arm and one in libgloss/arm. It appears that they were the same file originally, but lack of cross-maintenance means that they have accidentally diverged. There may also be some other files that have diverged. I haven't checked them all. The newlib/README file says --disable-newlib-supplied-syscalls is the default. But the configure code makes --enable-newlib-supplied-syscalls the default. The libgloss arm specs files could perhaps be changed to put libgloss libraries in front of newlib libraries, which may allow alternative rom monitors to work without rebuilding the toolchain. I haven't tried that. Currently, they include -lc first and then the monitor library, which won't work unless newlib is configured to disable the syscall support. There is also a related problem here that some of the specs files are redefining link spec to add -l$(monitorlib). That causes the archive file to be included before any input files on the link line, which means it will get ignored. The correct specs files are using link_gcc_c_sequence. It is OK to put a -T*.ld linker script file in link spec, but libraries need to go into link_gcc_c_sequence. And of course, arm supports this but aarch64 does not, and it seems to be general policy that things should work similarly for the two targets. So I count 5 inter-related newlib arm/aarch64 problems that need to be fixed.
By the way I will doing some bare metal aarch64 work soon but will be using a different triplet for this env as it supports a few things the standard bare metal does not.
(In reply to Andrew Pinski from comment #2) > By the way I will doing some bare metal aarch64 work soon but will be using > a different triplet for this env as it supports a few things the standard > bare metal does not. How soon do you mean specifically?
The Arm builds that do not need anything from libgloss (and thus do not need a specs file) while linking come from a configuration that hard codes the underlying runtime monitor (usually the arm semihosting ABI) directly into newlib. I understand that's deprecated and was not implemented for AArch64.
(In reply to Richard Earnshaw from comment #4) > The Arm builds that do not need anything from libgloss (and thus do not need > a specs file) while linking come from a configuration that hard codes the > underlying runtime monitor (usually the arm semihosting ABI) directly into > newlib. > > I understand that's deprecated and was not implemented for AArch64. So does this bug need to stay open then?