Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-22 Thread Paolo Bonzini
On 22/08/2017 18:04, Laszlo Ersek wrote: >> That said, the extra "-Wl," in "-Wl,-pie" is not necessary; the compiler >> driver knows "-pie" and swallows it when compiling (and passes it to the >> linker). > Now *that* I can get behind. If this works, then please let us do it -- > replace "-fpie" wi

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-22 Thread Laszlo Ersek
On 08/22/17 16:15, Paolo Bonzini wrote: > On 22/08/2017 16:03, Ard Biesheuvel wrote: >> On 22 August 2017 at 14:27, Paolo Bonzini wrote: >>> On 22/08/2017 13:59, Laszlo Ersek wrote: This seems to suggest that "-pie" is the *master* switch (used only when linking), and "-fpie" is a *prere

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-22 Thread Paolo Bonzini
On 22/08/2017 16:03, Ard Biesheuvel wrote: > On 22 August 2017 at 14:27, Paolo Bonzini wrote: >> On 22/08/2017 13:59, Laszlo Ersek wrote: >>> This seems to suggest that "-pie" is the *master* switch (used only when >>> linking), and "-fpie" is a *prerequisite* for it (to be used both when >>> link

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-22 Thread Ard Biesheuvel
On 22 August 2017 at 14:27, Paolo Bonzini wrote: > On 22/08/2017 13:59, Laszlo Ersek wrote: >> This seems to suggest that "-pie" is the *master* switch (used only when >> linking), and "-fpie" is a *prerequisite* for it (to be used both when >> linking and compiling). Is this right? >> >> If so, t

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-22 Thread Paolo Bonzini
On 22/08/2017 13:59, Laszlo Ersek wrote: > This seems to suggest that "-pie" is the *master* switch (used only when > linking), and "-fpie" is a *prerequisite* for it (to be used both when > linking and compiling). Is this right? > > If so, then I think this is a gcc usability bug. We don't genera

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-22 Thread Gao, Liming
iamson > ; Justen, Jordan L > ; Gao, Liming ; Kinney, > Michael D ; Paolo Bonzini > > Subject: Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large > code model for X64/GCC5/LTO > > On 08/22/17 10:00, Shi, Steven wrote: > > It is a link flag misuse in our

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-22 Thread Laszlo Ersek
On 08/22/17 10:00, Shi, Steven wrote: > It is a link flag misuse in our GCC build toolchains, not > compiler/linker's problem. Below patch can fix the wrong assembly > function relocation type in PIE binary. With below patch, all the > GCC5, GCC49 and GCC48 can build correctly images of OvmfPkgIa32

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-22 Thread Shi, Steven
iamson > ; Ard Biesheuvel > ; Justen, Jordan L ; > Gao, Liming ; Kinney, Michael D > > Subject: Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to > large code model for X64/GCC5/LTO > > On 08/12/17 05:05, Shi, Steven wrote: > > OK. I can reproduce t

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-15 Thread Laszlo Ersek
On 08/12/17 05:05, Shi, Steven wrote: > OK. I can reproduce the failure with -smp 4 and -m 5120 in my side. > > It looks a linker bug about assemble function support in PIC/PIE > code. You know, if we only have C code, the compiler/linker will > generate all the machine code and guarantee all the

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-11 Thread Shi, Steven
el-01 de...@lists.01.org> > Cc: Ard Biesheuvel ; Justen, Jordan L > ; Gao, Liming ; Kinney, > Michael D > Subject: Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large > code model for X64/GCC5/LTO > > Hi Steven, > > On 08/11/17 07:28, Shi, Steven wr

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-11 Thread Alex Williamson
On Fri, 11 Aug 2017 02:34:26 +0200 Laszlo Ersek wrote: > Cc: Alex Williamson > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Liming Gao > Cc: Michael Kinney > Cc: Yonghong Zhu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Laszlo Ersek > --- > BaseTools/Conf/tool

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-11 Thread Laszlo Ersek
Hi Steven, On 08/11/17 07:28, Shi, Steven wrote: > Hi Laszlo, > > I'm trying to reproduce your boot failure with OVMF in my Ubuntu > system, but not succeed. My GCC was built from GCC main trunk code > in 20170601, and my ld linker is version 2.28. Could you try the ld > 2.28 with your gcc-7.1 a

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-11 Thread Laszlo Ersek
On 08/11/17 12:03, Ard Biesheuvel wrote: > On 11 August 2017 at 01:34, Laszlo Ersek wrote: >> (2) Unfortunately, the C-language assignment to >> "MP_CPU_EXCHANGE_INFO.InitializeFloatingPointUnitsAddress" is >> miscompiled under the following circumstances: >> >> - the edk2 build targe

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-11 Thread Ard Biesheuvel
On 11 August 2017 at 01:34, Laszlo Ersek wrote: > Several users have recently reported boot failures with OVMF. The symptoms > are: blank screen and all VCPUs pegged at 100%. Alex Williamson has found > the commit (via bisection) that exposes the issue. In this patch I'll > attempt to analyze the

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

2017-08-10 Thread Shi, Steven
Hi Laszlo, I'm trying to reproduce your boot failure with OVMF in my Ubuntu system, but not succeed. My GCC was built from GCC main trunk code in 20170601, and my ld linker is version 2.28. Could you try the ld 2.28 with your gcc-7.1 and check whether it works in your side? Or, do you know wh