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.
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