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

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/31/12 16:28, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20121031224825.GA24095@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.

Right.  The flip side to this is that the Linux kernel also uses gcc
to link, depends on gcc doing what it's told and telling the linker
what we want and has a tad more clout than we do when problems arise.
 If we switch and we find a problem, it's likely the kernel can or
does fail as well, which can be useful in getting people to address bugs.

[snip]
>> 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.

I appreciate your restraint here.  And, I agree that we don't need to
bring this in until we've investigated LTO and found it brings
benefits to the project.  It could indeed mess up and not obey the
times we've re-ordered code segments out of necessity rather than
space optimization.  But it might also let us stop playing those games
and get better results with all of the text together.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQkbalAAoJENk4IS6UOR1WdMIP/RjcFHw0kvi17TJRvNq8sPzb
kEODknbkE/tw8GFa0QA3+Cp4AsmadDPA/KM4jfOypR3lpWey5oI25I5RRdnHvXbT
Cagp8Oyg9rqjD+VS8iVYIFMGy3/ivvwXzgysQlqhF/KFx07kcu+g2EG9rgZEP3cA
rNdZKG5NT1aq8iiu28Il1vY/nnYtDFBi1undhOzVi9pOlt5k9Vc3VhHB+3ZIzzrf
9ptvo1ORObQ1M3BISA7dZfYdITUElbqDQKLbqldUbWbBN/gaOsNvGWaAtCjOgoXo
O70mqe7Tqjl8p7S55jCBrZPuxNOHOs5HSOt/Q+o164RFXspvXV5fL9dX7HWE3wtL
y4asCLS3rmLkuY14dn7eXP3Mg4ZumtJST06SWfYYsAqD8EfFWfdye1gMpLUMwrKR
kWsmflyQbaXqAMhxdbhHeYPA3Spmwm0Ebgf8MjvZTpzWjyvKKsNm8Cgszr5n9Crz
YLIYFqG1NIopZ3SewsWckOkGbC9RatpfydDhbZ/F+u/oGu1jbWOLyuvUkTN75E/r
YPN5CZ7EOSVCuKz5NeUwuTdnVQqPxO1Hq3mtvxfbRIPDlEQ4XO5PdKqj+iwjqTyy
+0NYXyFSSf5ulPY7YeAHEj12kTBLvDD2QMgK0AHgMJ42N1ir4PQJrfP4DwZKxUdm
NHX2XryIFZs+C4hCiCgq
=q/MN
-----END PGP SIGNATURE-----