[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1361356696.13482.269.camel@i7.infradead.org>
Date: Wed, 20 Feb 2013 10:38:18 +0000
From: "Woodhouse, David" <david.woodhouse@...el.com>
To: Nicolas Pitre <nico@...xnic.net>
CC: Kim Phillips <kim.phillips@...escale.com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Borislav Petkov <bp@...en8.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Daniel Santos <daniel.santos@...ox.com>,
David Rientjes <rientjes@...gle.com>,
Rusty Russell <rusty@...tcorp.com.au>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Rob Herring <robherring2@...il.com>
Subject: Re: [RFC] arm: use built-in byte swap function
On Tue, 2013-02-19 at 22:17 -0500, Nicolas Pitre wrote:
>
> > +$(obj)/bswapsdi2.o: $(obj)/../../../../arch/$(SRCARCH)/lib/bswapsdi2.o
> > + $(call cmd,shipped)
> > +
>
> I don't think you can get away with this. The decompressor code is
> compiled with -fpic and the main kernel is not. Most toolchains do mark
> object files with some flags to prevent the link of incompatible objects
> together (normally pic and non pic objects are not compatible even if in
> this very simple case that would not matter). Maybe you are able to
> link zImage successfully simply because no references to __bswap* needed
> to be resolved and therefore the linker didn't need to search/include
> that object?
This, and the issue with -Os vs. -O2, make me inclined to suggest that
we should just provide an asm version of these functions instead of
using the compiler.
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6242 bytes)
Powered by blists - more mailing lists