https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66203

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
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.

Reply via email to