[U-Boot] [PATCH] common: Link with GCC instead of LD

[Wolfgang Denk]

Dear Tom,

In message <20121031224825.GA24095 at bill-the-cat> you wrote:
> 
> > > Flip over from linking with LD to linking with GCC. This has some
> > > long-term benefits, like easy path to enabling LTO.
> > 
> > Could you please explain these supposed benefits in a bit more detail?
> > Please excuse my ignorance, but so far I see just added complexity,
> > but I don't see what it buys us.
>
> Complexity is arguable.  Most projects don't call ld directly but let
> gcc call ld.  Doing this brings us in line with what other projects do.

The question is if there are good reasons for these other projects
doing it this way - I tend to belive most projects just don't care
that much about specific linker options - on the other hand, for bare
metal code like U-Boot it is essential to know _exactly_ how the
linker is being run.  Depending here on the GCC framework which may
meddle with options in subtle ways that are not always perfectly
understood is something that needs thorough consideration.

> As an aside, from my time with CodeSourcery folks directly calling ld
> was discouraged I swear, but I don't have some reference to back that

I agree with this for "normal programs", i. e. standard conformng code
in a standard C environment, where correct use of the appropriate GCC
runtime environment and standard libraries is essential.  But none of
this applies to U-Boot.

> up.  Finally, as Marek said but didn't explain, this brings us a step
> closer to being able to enable LTO (link time optimization) which may
> (but we need to experiment) be beneficial in terms of size and
> performance (since in short gcc re-decides things like positioning,
> inlining based on the whole program state at link time).

I do understand this argument.  But unless I've seen this working in a
real test case I don't feel conficent to acept this.  Changing "things
like positioning" etc. is something we usually do now want to allow
here - instead, we want to have absolute control over such things.

Until I see any such things implemented (and working), this patch
falls for me in the group of "unused code" - and given the added
complexity (which is definitely non-trivial) it takes me a lot of
discipline not to NAK this right away.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is, however, a strange, musty smell in the air that reminds  me
of something...hmm...yes...I've got it...there's a VMS nearby, or I'm
a Blit.          - Larry Wall in Configure from the perl distribution