From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Thu, 01 Nov 2012 00:28:04 +0100 Subject: [U-Boot] [PATCH] common: Link with GCC instead of LD In-Reply-To: <20121031224825.GA24095@bill-the-cat> References: <1351701168-7293-1-git-send-email-marex@denx.de> <20121031223618.E2C15200630@gemini.denx.de> <20121031224825.GA24095@bill-the-cat> Message-ID: <20121031232804.5ABDA2005BD@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 -- 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