Re: [PATCH] ld/ldlang.c: fatal error on architecture mismatch

[Richard Sandiford <richard at codesourcery dot com>]

erik@dd.nec.com.au (Erik Christiansen) writes:
> Having also advocated that the script would never be ignored, i.e.
> "whether _start or ENTRY() exist is explicitly up to the programmer", I
> can only agree totally. But Nick's case (IIUC), and mine, arise when
> your "if" is not satisfied.  ;-) 
>
> IIUC, the "problem" only arises where a programmer _hasn't_ specified an
> entry point in the linker script, and hasn't provided _start (*), but wishes
> he had. The result is that the first build of the project doesn't run.
> Does that warrant breaking existing builds?  :-)
>
> Maybe it does, but is it perhaps enough to put "ENTRY(_start);" in the
> default linker scripts instead? Existing projects would use existing
> scripts, and wouldn't break. A new embedded project would start with
> customising a default linker script, mandating a named entry point by
> default. Could that please both camps?

Ah, it seems we're talking about different cases then.

The default linker scripts already have "ENTRY(_start);" (or a target-
specific equivalent).  The angle I was coming from -- and I think Dan
was coming from -- is that that's a good thing.  You should get an error
if you use the default linker script and don't provide a definition of
its designated entry point.  You should also get an error if your
custom linker script has "ENTRY (foo)" and you don't define foo.
It sounds like you're OK with that.  (This is the bit that Ian says
will break existing builds though.  The user has blindly copied the
ENTRY statement from the default linker script, hasn't defined the
symbol, and is currently ignoring what is only a warning.)

It sounds like you're talking about the default entry point that's
compiled into the linker itself.  I agree that if the linker script
has no ENTRY point, the warning about not defining the compiled-in
symbol should remain a warning.

Richard