ARM EABI -specs=nosys crt0.o not being linked in

ARM EABI -specs=nosys crt0.o not being linked in

[Schwarz, Konrad]

Hi,

In my project, the linker reports the error 
[...]/../../../../arm-atollic-eabi/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 08000800
This means that crt0.o is not being linked in.

GCC -dumpspecs defines startfile as
*startfile:
 crti%O%s crtbegin%O%s

I am runnig gcc with -specs=nosys; nosys.specs does not mention crt0.o.  However, several of the other newlib-supplied spec files do override startfile; e.g. rdimon.specs:
*startfile:
crti%O%s crtbegin%O%s %{!pg:rdimon-crt0%O%s} %{pg:rdimon-crt0%O%s}

To my thinking, nosys.specs, rdimon.specs, rdpmon.specs, linux.specs, pid.specs, ... are mutually exclusive, since each defines an interface to a "BIOS".  It follows that nosys.specs should be properly defining startfile.  Is that correct?  Or is nosys.specs orthogonal to the other spec files, and a new spec file "baremetal.specs" that basically overrides startfile is needed?  Or is the breakage somewhere else?

Gcc I am using: arm-atollic-eabi-gcc.exe (GNU Tools for ARM Embedded Processors (Build 16.04-3)) 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589]

_NEWLIB_VERSION is "2.4.0" according to include/_newlib_version.h

Thanks
Konrad

Re: ARM EABI -specs=nosys crt0.o not being linked in

[Hans-Bernhard Bröker]

Am 30.03.2017 um 08:54 schrieb Schwarz, Konrad:

> To my thinking, nosys.specs, rdimon.specs, rdpmon.specs, linux.specs,
> pid.specs, ... are mutually exclusive, since each defines an
> interface to a "BIOS".  It follows that nosys.specs should be
> properly defining startfile.  Is that correct?

I'd say no, it's not.  The name "nosys" should be read at face value: it 
says that there is _no_ system assumed.   Which gives you the 
opportunity to specify the details of how the system is get up out of 
reset, by specifying your own choice of start-up file explicitly, on the 
command line. But that also gives you the _obligation_ to actually do it.

Specs files exist to assist you with tailoring the compiler and tools to 
your system --- not to assume 100% of the job for every imaginable use case.