On Fri, Jun 08, 2012 at 11:19:36AM -0400, Vivek Goyal wrote:
> On Fri, Jun 08, 2012 at 04:51:13PM +0200, Jakub Jelinek wrote:
> > On Fri, Jun 08, 2012 at 10:39:49AM -0400, Vivek Goyal wrote:
> > > BTW, What does -mcmodel do and why should we use -mcmodel? purgatory, is a
> > > separate binary which we reloate at turn time based on physical memory
> > > location. IOW, why should we make any assumptions about running location
> > > of purgatory and pass -mcmodel flag.
> >
> > The default x86_64 -mcmodel=small requires that the binary (and all
> > corresponding data (rodata etc.) sections must be within the low 2GB of
> > address space. Kernel code is usually in the topmost 2GB of address space,
> > and -mcmodel=kernel is the memory model for that (all code and all other
> > sections must be in topmost 2GB of address space). Of course pointers
> > are 64-bit in both cases, so any memory you access solely through pointers,
> > not through symbols, can be anywhere. Haven't looked at where purgatory
> > relocates itself into the address space.
>
> IIRC, by the time purgatory runs we turn the paging off and we are
> operating in protected mode. And by that time purgatory is running from
> low 2GB of address space.
>
> It is relocated by kexec-tools itself before it calls kernel. So in
> user space we decide a physical address where purgatory can be run
> from. Relocate this binary so that it can run from that address and
> then call kernel to load this binary at this address. (Kernel might
> store the binary at some other location but it is moved to it final
> destination just before kexec and just before we jump to it).
>
> Relocation happens here.
>
> kexec-tools/kexec/arch/i386/kexec-bzImage.c
>
> ***********************************************************************
>
> /* Load the trampoline. This must load at a higher address
> * the the argument/parameter segment or the kernel will stomp
> * it's gdt.
> *
> * x86_64 purgatory code has got relocations type R_X86_64_32S
> * that means purgatory got to be loaded within first 2G otherwise
> * overflow takes place while applying relocations.
> */
> if (!real_mode_entry && relocatable_kernel)
> elf_rel_build_load(info, &info->rhdr, purgatory,
> purgatory_size,
> 0x3000, 0x7fffffff, -1, 0);
> else
> elf_rel_build_load(info, &info->rhdr, purgatory,
> purgatory_size,
> 0x3000, 640*1024, -1, 0);
> dbgprintf("Loaded purgatory at addr 0x%lx\n",
> info->rhdr.rel_addr);
>
> *************************************************************************
>
> So at this point of time, it does not look like that we should be passing
> -mcmodel for purgatory code.
>
> >
> > -mno-sse -mno-mmx will tell gcc not to use any %mmX or %xmmX registers.
> > i?86 also passes -msoft-float in addition to -mno-sse -mno-mmx I think.
> >
>
> Yes, i386 is also passing -msoft-float in kernel. Personally I have no
> issues in adding -mno-sse and -mno-mmx and -msoft-float for i386. It is
> that kind of thing that one gets the motivation to change these flags
> once something breaks down.
>
> [..]
> > > > hash computation unconditionally everywhere at -O0 must IMHO pessimize
> > > > things unnecessarily.
> > >
> > > git blame points to following commit for forcing -O0 on sha256. CCing
> > > Jermey, if we can give some details why -O2 was a problem on IA6 and
> > > if problem is still there if he has objections if we swtich back to -O2.
> > >
> > > commit adf85cbc1756e56c1f52f56235a3c08b3c5b8e05
> > > Author: Jeremy Kerr <jk at ozlabs.org>
> > > Date: Thu Dec 13 16:18:53 2007 +0900
> > >
> > > Build system simplification/standardisation
> >
> > I think the change was even older, this one just moved the -O0 CFLAGS from
> > one spot to a different one.
>
> You are right. Here is the original change.
>
> commit e90343c521b68237c17ea4e4ed376c4a726f0789
> Author: Simon Horman <horms at verge.net.au>
> Date: Fri Oct 6 12:27:58 2006 +0900
>
> build-util_lib-optimisation-flags
>
> [BUILD] Make sure sha256.c is compiled without optimisation
>
>
> It is almost 6 years old now. Simon, can it be changed to -O2 now?
I have no objections.
I will add your original patch. Do you want to provide a follow-up patch
as well?
