I've been trying to follow this discussion but I don't see the consensus.
Probably from my inexperience. Can someone summarize what works now, as
opposed to what should be done? Is
the solution the same for the 2.4kernel/gcc2.95 and the 2.6kernel/gcc3+?
Also are all of these comments appicable to little and big endian systems?
On Fri, 19 Sep 2003, Thiemo Seufer wrote:
> Maciej W. Rozycki wrote:
> > On Fri, 19 Sep 2003, Thiemo Seufer wrote:
> > > > > A third answer is to add a -msign-extend-addresses switch in the
> > > > > assembler.
> > > > > Together with -mabi=64 this would produce optimized ELF64 output.
> > > >
> > > > Hmm, what do you exactly mean -- is that what I am worrying about?
> > >
> > > The idea is to use the assembler's 32bit macro expansions for addresses.
> > So it is...
> > > This reduces the .text size of a n64 kernel and improves the performance,
> > > without tricks like -Wa,32.
> > What if the final link leads to segments being mapped outside the 32-bit
> > address range? We won't know about it when assembling.
> Then the resulting code is broken. It's the programmers responsibility
> to care about it. IMHO that's not a problem, this feature is only
> useful for kernels, and the tricks currently done there are worse.
> > If the idea were to be implemented, there should be a flag added to the
> > header of object files that would forbid the linker to map addresses
> > outside the 32-bit range.
> Please don't add any header flag. An additional (.note?) section would
> be nice, but is not a priority for me.