From mboxrd@z Thu Jan  1 00:00:00 1970
From: Haiying Wang <Haiying.Wang@freescale.com>
Date: Fri, 4 Feb 2011 10:52:38 -0500
Subject: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
In-Reply-To: <20110201144013.5924e63f@udp111988uds.am.freescale.net>
References: <1296498767-26408-1-git-send-email-Haiying.Wang@freescale.com>
	<20110131193309.745E7D4D67C@gemini.denx.de>
	<20110131135548.50d65759@udp111988uds.am.freescale.net>
	<20110201073401.1B343B187@gemini.denx.de>
	<20110201102446.23b4a2e9@udp111988uds.am.freescale.net>
	<20110201193229.7C545B187@gemini.denx.de>
	<20110201135136.0817fe5a@udp111988uds.am.freescale.net>
	<20110201202050.CA1CFB187@gemini.denx.de>
	<20110201144013.5924e63f@udp111988uds.am.freescale.net>
Message-ID: <1296834758.1963.26.camel@haiying-laptop>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Wolfgang,

On Tue, 2011-02-01 at 14:40 -0600, Scott Wood wrote: 
> On Tue, 1 Feb 2011 21:20:50 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> 
> > Dear Scott Wood,
> > 
> > In message <20110201135136.0817fe5a@udp111988uds.am.freescale.net> you wrote:
> > >
> > > > > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > > > > used?  So before, anything that board/cpu code adds directly to LDFLAGS
> > > > > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > > > > used in the final link.  After 8aba9dc, only things in
> > > > > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> > > > 
> > > > And this is correct for all boards?
> > > 
> > > By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> > > switch back to LDFLAGS?  It's not obvious to me that the dropping of
> > 
> > I don;t understand why you contine to talk about "switch to
> > PLATFORM_LDFLAGS in 8aba9dc".  There was no such switch - at least I
> > cannot see it.
> > 
> > I see only a switch in your patch.  This is why I'm asking.
> 
> Before 8aba9dc, the flags for the final link were produced by taking
> the existing LDFLAGS, and adding:
> -Bstatic -T <linkerscript> $(PLATFORM_LDFLAGS) -Ttext <addr>.
> 
> This included anything that cpu/board code added to LDFLAGS -- some
> architectures added --gc-sections, x86 added --cref, etc.  Since the above
> flags are added to LDFLAGS, rather than replacing them, these flags got used
> in the final link.
> 
> Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the
> source for the flags for the final link.  It generates LDFLAGS_u-boot using
> PLATFORM_LDFLAGS, not LDFLAGS.  It converts most of the board/cpu updates to
> LDFLAGS into LDFLAGS_u-boot, but it missed --cref.
> 
> I don't see any other LDFLAGS changes in board/cpu code, so the distinction
> between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on
> current boards.  However, the patch appears to be intended to support
> platform linker flags that need to be used during partial link, which
> would involve board/cpu additions to LDFLAGS.  This change would break that
> only if those options need to be used for partial link *only*, and cannot be
> used in the final link.  In such a case I'd suggest using something like
> LDFLAGS_PARTIAL to make this explicit.  But I'd be surprised if that
> were actually the case.
> 
> If you're looking to cut down on the number of variables, it's not clear to
> me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to
> LDFLAGS.
> 
> -Scott

Do you have time to read Scott's email and give us any further
recommendation? We do need to solve the issues of partial linking caused
by commit 8aba9dc.

Thanks.

Haiying