The ordinary small code model for x86_64 cannot be used in UEFI, since
it assumes the executable is loaded in the first 2 GB of memory.
Therefore, we use the large model instead, which can execute anywhere,
but uses absolute 64-bit wide quantities for all symbol references,
which is costly in terms
GCC v4.4 does not implement __builtin_unreachable(), so avoid using
it when building with this version or earlier.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Tested-by: Laszlo Ersek
---
MdePkg/Include/Base.h | 3 ++-
1 file changed, 2 insertions(+), 1
From: "Shi, Steven"
Both GCC and LLVM 3.8 64bits support new variable argument (VA)
intrinsics for Microsoft ABI, enable these new VA intrinsics for
GNUC family 64bits code build. These VA intrinsics are only
permitted use in 64bits code, so not use them in 32bits code build.
The original 32bits
When building position independent (PIC) ELF objects, the GCC compiler
assumes that each symbol with external linkage may potentially end up
being exported from a shared library, which means that each of those
symbols may be subject to symbol preemption, i.e., the executable
linking to the shared l
This is v2 of the series to enable compiler optimization under GCC for builds
targetting X64. It includes a patch from Steven Shi, taken from his series to
introduce support for GCC 5.x and Clang 3.8/X64 to EDK2.
The first patch fixes the issue that __builtin_unreachable() is not
implemented by GC
Now that we switched to the __builtin_ms_va_list VA_LIST type for
GCC/X64, we can trust the compiler to do the right thing even under
optimization, and so we can enable -Os optimization all the way back
to GCC44, and drop the -D define that prevents the use of the __builtin
VA_LIST types. Note that
On 15 July 2016 at 12:37, Laszlo Ersek wrote:
> On 07/15/16 12:15, Ard Biesheuvel wrote:
>> On 15 July 2016 at 11:51, Laszlo Ersek wrote:
>
>>> What I'd be most interested in is
>>> enabling optimization (saving space) for -b DEBUG -- I don't do source
>>> level debugging, but I want the debug me
Of all the gin joints in all the towns in all the world, Cohen, Eugene had to
walk into mine at 05:32:47 on Friday 15 July 2016 and say:
> Shaveta,
>
> > Have you tried some optimizations to get better performance in UEFI code
If I may ask, what device driver code are you using? I think earlier
Thanks again for your validations, and the reminder on Install.sh (which was
really one issue. I made several mistakes on this CRLF/LF usage before).
Best Regards & Thanks,
LONG, Qin
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, July 15, 2016 7:29
Laszlo, thanks for comments.
You are right. The current patch file (EDKII_openssl-1.0.2h.patch) still use
the CRLF line ending, which may be warned when you apply the patch file. It is
one historical issues from old version (on Windows). I agree it's better to
have native LF here. For this upda
Patch series - Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Thursday, July 14, 2016 7:40 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v2 00/27] ShellPkg: Handle memory allocation fai
Hi all,
Just thought I should give a heads up that both myself and Ard will be
unavailable next week. I will be back on the 25 July, and Ard a week
after that.
Apologies for any inconvenience.
Regards,
Leif
___
edk2-devel mailing list
edk2-devel@lists
Shaveta,
> Have you tried some optimizations to get better performance in UEFI code
I think the question you should be asking is how do you measure how the current
code is performing, this is a tools and methodology thing. With ARM there are
all sorts of options from JTAG debuggers that can sa
On 07/15/16 12:46, Laszlo Ersek wrote:
> Qin Long,
>
> On 07/13/16 08:15, Qin Long wrote:
>> OpenSSL 1.0.2h was released with several severity fixes at
>> 03-May-2016 (https://www.openssl.org/news/secadv/20160503.txt).
>> Upgrade the supported OpenSSL version in CryptoPkg/OpensslLib to
>> catch th
Qin Long,
On 07/13/16 08:15, Qin Long wrote:
> OpenSSL 1.0.2h was released with several severity fixes at
> 03-May-2016 (https://www.openssl.org/news/secadv/20160503.txt).
> Upgrade the supported OpenSSL version in CryptoPkg/OpensslLib to
> catch the latest release 1.0.2h.
>
> Cc: Ting Ye
> Cc:
On 07/15/16 12:15, Ard Biesheuvel wrote:
> On 15 July 2016 at 11:51, Laszlo Ersek wrote:
>> What I'd be most interested in is
>> enabling optimization (saving space) for -b DEBUG -- I don't do source
>> level debugging, but I want the debug messages and the ASSERT()s. Saving
>> space with those c
On 15 July 2016 at 11:51, Laszlo Ersek wrote:
> On 07/15/16 11:25, Ard Biesheuvel wrote:
>> On 15 July 2016 at 11:06, Laszlo Ersek wrote:
>
>>> And, to our collective relief, this means that there should be no
>>> problem with this series. :) I think I can add my Tested-by:
>>>
>>> Tested-by: Las
On 14/07/2016 16:57, Ard Biesheuvel wrote:
>> > On patch 5, I don't see any change for IA32 arch. is there no mode for
>> > IA32 arch? Here, small and pic must be enabled together, right? Otherwise,
>> > the assumption is to load driver below 2G address. Have you collected size
>> > data bef
On 07/15/16 11:25, Ard Biesheuvel wrote:
> On 15 July 2016 at 11:06, Laszlo Ersek wrote:
>> And, to our collective relief, this means that there should be no
>> problem with this series. :) I think I can add my Tested-by:
>>
>> Tested-by: Laszlo Ersek
>>
>
> Thanks a lot!
>
> I do have another
If the NASM_PREFIX variable is not set, it would report warning message.
If there exist the C:\nasm\nasm.exe file, it would set the NASM_PREFIX
variable to C:\nasm\.
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu
---
edksetup.bat | 10
On 15 July 2016 at 11:06, Laszlo Ersek wrote:
> On 07/15/16 10:58, Ard Biesheuvel wrote:
>> On 15 July 2016 at 10:48, Laszlo Ersek wrote:
>>> On 07/15/16 10:40, Ard Biesheuvel wrote:
On 15 July 2016 at 08:33, Laszlo Ersek wrote:
> On 07/15/16 08:07, Ard Biesheuvel wrote:
>> On 15 Ju
>From efe33f933f6004951131920c9af33d338e92c6dc Mon Sep 17 00:00:00 2001
From: david wei
Date: Fri, 15 Jul 2016 17:06:29 +0800
Subject: [PATCH] Disable Spread Spectrum of On-chip Devices.
Disable Spread Spectrum of on-chip devices temporarily, because it causes hang
issue after system resets abo
On 07/15/16 10:58, Ard Biesheuvel wrote:
> On 15 July 2016 at 10:48, Laszlo Ersek wrote:
>> On 07/15/16 10:40, Ard Biesheuvel wrote:
>>> On 15 July 2016 at 08:33, Laszlo Ersek wrote:
On 07/15/16 08:07, Ard Biesheuvel wrote:
> On 15 July 2016 at 01:27, Laszlo Ersek wrote:
>> Fir
Reviewed-by: Ruiyu Ni
Thanks,
Ray
> 在 2016年7月15日，下午4:14，Laszlo Ersek 写道：
>
> When compiling "OvmfPkg\Library\PciHostBridgeLib\XenSupport.c" for IA32,
> the VS2015x86 compiler emits the following:
>
>> XenSupport.c(41): error C2220: warning treated as error - no 'object'
>>
On 15 July 2016 at 10:48, Laszlo Ersek wrote:
> On 07/15/16 10:40, Ard Biesheuvel wrote:
>> On 15 July 2016 at 08:33, Laszlo Ersek wrote:
>>> On 07/15/16 08:07, Ard Biesheuvel wrote:
On 15 July 2016 at 01:27, Laszlo Ersek wrote:
>>>
> First, the build tests. I built OVMF 84 times, with
On 07/15/16 10:40, Ard Biesheuvel wrote:
> On 15 July 2016 at 08:33, Laszlo Ersek wrote:
>> On 07/15/16 08:07, Ard Biesheuvel wrote:
>>> On 15 July 2016 at 01:27, Laszlo Ersek wrote:
>>
First, the build tests. I built OVMF 84 times, with the following settings:
* Dimension 1: wheth
Laszlo:
Your patches (total 5) are good to me. Reviewed-by: Liming Gao
Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, July 15, 2016 4:14 PM
> To: edk2-devel-01
> Cc: Andrew Fish ; Fan, Jeff ; Justen,
> Jordan L ; Gao, Liming ;
> Ki
On 15 July 2016 at 08:33, Laszlo Ersek wrote:
> On 07/15/16 08:07, Ard Biesheuvel wrote:
>> On 15 July 2016 at 01:27, Laszlo Ersek wrote:
>
>>> First, the build tests. I built OVMF 84 times, with the following settings:
>>>
>>> * Dimension 1: whether your and Steven's patches were applied or not.
> cc1: warnings being treated as errors
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c:
> In function 'GetProposedResources':
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c:1388:
> error: integer constant is too large for 'long' type
Append a ULL suffix to the replacement tex
VS2015x86 reports the following warning for
"OvmfPkg/PlatformPei/MemDetect.c":
> MemDetect.c(357): error C2220: warning treated as error - no 'object'
> file generated
> MemDetect.c(357): warning C4244: '=': conversion from 'UINT64' to
> 'UINT32', possible loss
Commits 28ee5816465b1 and 246cd9085f806 added these ENDs as part of the
manual conversion from *.asm files. However, the ENDs makes no sense for
NASM. Although they don't break the build, NASM complains about them:
label alone on a line without a colon might be in error
(This NASM warning categ
So I've finally managed to set up VS2015x86 for test-building OVMF.
Thanks Jordan and Liming for the instructions back in April (IIRC). The
setup was a total pain, in no small part because there are three
competing git implementations for Windows (cygwin, msys, and the
standalone package from the g
When compiling "OvmfPkg\Library\PciHostBridgeLib\XenSupport.c" for IA32,
the VS2015x86 compiler emits the following:
> XenSupport.c(41): error C2220: warning treated as error - no 'object'
>file generated
> XenSupport.c(41): warning C4244: 'function': conversion fro
NASM had been unable to assemble segment register operations before the
following git commit:
http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338
That commit was first released in NASM 2.10:
http://repo.or.cz/nasm.git/commitdiff/ff62f33da0a2
This makes NASM 2.07 unusable for edk2 in general,
In latest UEFI2.6 spec, the type of the fourth parameter in function
GetImageInfo() is "EFI_IMAGE_OUTPUT", but in the header file, it is
"EFI_IMAGE_INPUT". Now correct it to follow the spec.
Cc: Liming Gao
Cc: Eric Dong
Cc: Cecil Sheng
Cc: Abner Chang
Contributed-under: TianoCore Contributio
On 07/15/16 07:18, Laszlo Ersek wrote:
> On 07/15/16 02:12, Jordan Justen wrote:
>> On 2016-07-13 07:36:58, Laszlo Ersek wrote:
>>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>>> index 805650059e96..8af326778205 100644
>>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>>> +++ b/OvmfPkg/OvmfPkg
Ard:
The error message shows the error happens in the first loop in VA_START and
VA_END. Could we update the logic to use single va list and verify it again? If
the single va list passes, it can prove your suspect. If the single va list
still fail, it may be other issue. I think we need to kno
37 matches
Mail list logo
