[edk2] [Patch] MdeModulePkg LoadFileOnFv2: Fix the potential NULL pointer access

Check NULL pointer before access it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

Re: [edk2] [Patch] MdeModulePkg UefiBootManagerLib: Fix VS2012 build failure

Reviewed-by: Feng Tian Thanks Feng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming Gao Sent: Tuesday, August 2, 2016 10:36 AM To: edk2-devel@lists.01.org Subject: [edk2] [Patch] MdeModulePkg UefiBootManagerLib: Fix

Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

Ard: This update works. It is better. For my question, I get the answer from your previous patch. Please ignore it. Patches 3&4&6&8 are good to me. Reviewed-by: Liming Gao Thanks Liming > -Original Message- > From: edk2-devel

[edk2] Foreign keyboard support in UEFI

Hi, Any one shed some light on supporting multi language key board support on UEFI application? Scan code received from EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL not returns value for certain keys in German/Arabic USB keyboard. We are also not sure in mapping UEFI code from

Re: [edk2] [patch] BaseTool/UPT: Add Test Install

Please remove the trailing whitespace when commit. Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Chen, Hesheng Sent: Friday, July 29, 2016 3:58 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong Subject:

Re: [edk2] [patch] BaseTool/Upt: Avoid UNI file name conflict

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Chen, Hesheng Sent: Friday, July 29, 2016 2:09 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong Subject: [patch] BaseTool/Upt: Avoid UNI file name conflict

Re: [edk2] [patch 2/2] BaseTool/Upt: Add support for Private

Please remove the trailing whitespace when commit. Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Chen, Hesheng Sent: Friday, July 29, 2016 10:31 AM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong

Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

The supported cipher suite should be one self-defined scope (I am not sure if any minimal sets for TLS from RFC/Spec. Need to double-check). It's one typical cipher negotiation process in TLS protocol. Tell the peer what I support, what you support, then agree one set supported by both. We can

Re: [edk2] [PATCH] MdePkg: move to 'hidden' visibility for all symbols under GCC/X64

Reviewed-by: Liming Gao > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, August 01, 2016 2:57 PM > To: Shi, Steven ; Zhu, Yonghong > ; Gao, Liming ;

Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

Ard: I will verify it. And, I would ask why only X64 requires it? IA32, ARM and AARCH64 doesn't specially handle it? Thanks Liming > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, August 02, 2016 12:12 AM > To: Gao, Liming

[edk2] [Patch] MdeModulePkg LoadFileOnFv2: Correct copy right format

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c

Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Thomas, Thanks your effort to test the new ciphers, can you provide the info which one is unsupported currently? As Qin's comments, "we'd better to keep the current supported cipher suite for our UEFI- TLS enabling". If so, I agree to remove the unsupported one in TlsCipherMappingTable

Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

Tim: FDF syntax doesn't support .ffs. Thanks Liming > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Tim Lewis > Sent: Tuesday, August 02, 2016 1:03 AM > To: Justen, Jordan L ; Kinney, Michael D >

Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Hi Jiaxin, It sounds like we both agree that TlsCipherMappingTable is the list of what UEFI officially supports. If it is advertised in TlsCipherMappingTable then OpenSSL needs to support it. My proposal of removing no-dsa / no-idea and adding weak-ciphers is specifically

Re: [edk2] [PATCH] OvmfPkg: use StatusCode Router and Handler from MdeModulePkg

On 08/01/16 09:08, Cinnamon Shia wrote: > Use StatusCode Router and Handler from MdeModulePkg instead of > IntelFrameworkModulePkg. > > MdeModulePkg ones follows PI spec to implement StatusCode > Router/Handler and provide StatusCode service. > It allows the different status code handlers to be

Re: [edk2] [PATCHV2] MdePkg: Add DmaRemappingReportingTable.h

Giri, The updates look good. Reviewed-by: Michael Kinney Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Giri P > Mudusuru > Sent: Monday, August 1, 2016 4:17 PM > To: edk2-devel@lists.01.org > Cc: Kinney,

[edk2] [PATCHV2] MdePkg: Add DmaRemappingReportingTable.h

DMA Remapping Reporting (DMAR) ACPI table definitions from Intel(R) Virtualization Technology for Directed I/O (VT-D) Architecture Specification v2.4 dated June 2016. This replaces the DMARemappingReportingTable.h from EdkCompatibilityPkg\Foundation\Include\IndustryStandard Patch V2: added below

Re: [edk2] [PATCH] IntelFsp2Pkg: Locate FSP Info Header dynamically

Reviewed-by: Giri P Mudusuru Please update the comments for the opcode to be in line similar to the https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm Thanks, -Giri > -Original Message- > From: Yarlagadda, Satya P > Sent:

Re: [edk2] [PATCH] IntelFsp2Pkg: Locate FSP Info Header dynamically

It looks good to me. Reviewed by: Maurice Ma Regards, Maurice -Original Message- From: Yarlagadda, Satya P Sent: Monday, August 01, 2016 4:42 AM To: edk2-devel@lists.01.org Cc: Ma, Maurice; Yao, Jiewen; Mudusuru, Giri P Subject: [PATCH] IntelFsp2Pkg: Locate FSP

Re: [edk2] [PATCH] ArmPkg/Library: Add ArmReadSctlr for aarch64

Thanks Ard. -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Monday, August 01, 2016 7:11 AM To: Supreeth Venkatesh Cc: edk2-devel-01; Leif Lindholm; John Powell Subject: Re: [PATCH] ArmPkg/Library: Add ArmReadSctlr for aarch64 On 30 July 2016 at 01:06,

Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Giri, Based on the information in this thread, I am in favor of adding to MdePkg. If the number of files in MdePkg/Include/IndustryStandard grows too large then some additional directory organization may be required. Mike > -Original Message- > From: Mudusuru, Giri P > Sent: Monday,

Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

Jordan -- As a company that delivers a lot of mixed binary/source builds, we see .depex as actually important for ease of maintenance. The .fdf syntax can work, as you mention, but it is actually requires an extra step for those of us maintaining binary modules. Why? Because .depex is derived

Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

Jordan, I agree that we should not be adding .efi binaries or .depex binary files to our source repos. There are several repos for EDK II, and some of those do accept binaries. Specifically, the edk2-non-osi and edk2-platforms would be repos where .depex may occur. Possibly edk2-staging as

Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Thanks for detailed conversation and I agree with direction. As it is ACPI related which has multiple vendors owning specific tables referred by ACPI spec MdePkg for now seems to be right place. That said we can start separate discussion if we want to create vendor folders for better

Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

On 1 August 2016 at 16:56, Ard Biesheuvel wrote: > On 1 August 2016 at 16:49, Ard Biesheuvel wrote: >> On 1 August 2016 at 16:18, Gao, Liming wrote: >>> Ard: >>> I don't think it is good way to define

[edk2] [patch] BaseTool/UPT: Not expand macro for UserExtension

All MACRO values defined by the DEFINE statements n any section (except [Userextensions] sections other than TianoCore."ExtraFiles) of the INF or DEC file must be expanded before processing of the file. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: hesschen

Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

On 1 August 2016 at 16:49, Ard Biesheuvel wrote: > On 1 August 2016 at 16:18, Gao, Liming wrote: >> Ard: >> I don't think it is good way to define GCC_VISIBILITY_PROTECTED and apply >> it in EntryPointLib. We only need to expose

Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

On 1 August 2016 at 16:18, Gao, Liming wrote: > Ard: > I don't think it is good way to define GCC_VISIBILITY_PROTECTED and apply > it in EntryPointLib. We only need to expose _ModuleEntryPoint. It has been > specified in LINK_FLAGS in tools_def.txt. Could we also specify

[edk2] [PATCH 2/2] MdeModulePkg/EbcDxe: cleanup

- indentation - premature optimization of the thunking code, i.e., align function prototypes so we don't have to move arguments around or duplicate them on the stack, and perform tail calls where possible - adhere to calling convention (stack frame layout) - replace instruction buffer with a

[edk2] [PATCH 1/2] MdeModulePkg/EbcDxe AARCH64: fix comment style

Replace '#' comments with '//' Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S | 92 ++-- 1 file changed, 44 insertions(+), 48 deletions(-) diff --git

Re: [edk2] [PATCH 1/2] BaseTools/GenFw AARCH64: convert ADRP to ADR if binary size allows it

Apologies, lost track of this one. On Mon, Aug 01, 2016 at 01:53:09PM +0200, Ard Biesheuvel wrote: > On 27 July 2016 at 13:26, Ard Biesheuvel wrote: > > The ADRP instruction in the AArch64 ISA requires the link time and load > > time offsets of a binary to be equal

Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

Ard: I don't think it is good way to define GCC_VISIBILITY_PROTECTED and apply it in EntryPointLib. We only need to expose _ModuleEntryPoint. It has been specified in LINK_FLAGS in tools_def.txt. Could we also specify its attribute in CC_FLAGS or LINK_FLAGS in tools_def.txt? Thanks Liming >

Re: [edk2] [PATCH 1/2] BaseTools/GenFw AARCH64: convert ADRP to ADR if binary size allows it

Ard: Your change is OK to me. I have no comment. Thanks Liming From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Monday, August 1, 2016 7:53 PM To: edk2-devel-01 ; Gao, Liming ; Zhu, Yonghong Cc: Leif Lindholm

Re: [edk2] [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

Ard, Where can I check out your v5 patch? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, August 01, 2016 4:01 PM > To: Shi, Steven ; Zhu,

Re: [edk2] [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

On 1 August 2016 at 16:01, Shi, Steven wrote: > Ard, > Where can I check out your v5 patch? > https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/gcc5-lto-v5 or git://git.linaro.org/people/ard.biesheuvel/uefi-next.git gcc5-lto-v5 Thanks, Ard.

Re: [edk2] Ingebrigtsen: The End of Gmane?

On 07/31/16 04:25, Bruce Cran wrote: > On 7/28/2016 1:19 PM, Andrew Fish wrote: > >> Seems he will send you the disks. What could go wrong? > > I'm actually tempted to take him up on that offer. > Just today I went looking for information about UefiDebugLib to see if > it was possible for a

Re: [edk2] [PATCH] ArmPkg/Library: Add ArmReadSctlr for aarch64

On 30 July 2016 at 01:06, Supreeth Venkatesh wrote: > One of the UEFI Self Certification tests (UEFI-SCT) need to read the > current exception level SCTLR Register. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: John Powell

Re: [edk2] [PATCH 1/2] BaseTools/GenFw AARCH64: convert ADRP to ADR if binary size allows it

On 27 July 2016 at 13:26, Ard Biesheuvel wrote: > The ADRP instruction in the AArch64 ISA requires the link time and load > time offsets of a binary to be equal modulo 4 KB. The reason is that this > instruction always produces a multiple of 4 KB, and relies on a

[edk2] [PATCH] IntelFsp2Pkg: Locate FSP Info Header dynamically

we need to locate the FSP Info Header by calculating offset dynamically to handle the scenario of FSP component is being rebased to different location. Cc: Maurice Ma Cc: Jiewen Yao Cc: Giri P Mudusuru Contributed-under:

[edk2] [patch 2/2] BaseTools/VfrCompile: Add two new option for VfrCompile

1.--autodefault option VfrCompile will generate default opcodes for questions if some default are missing. 2 --checkdefault option VfrCompile will check whether every question has no default or has all default. If not, will generate an error to let user know the question misses

[edk2] [patch 1/2] BaseTool/VfrCompile: Add missing question opcode

The function CheckQuestionOpCode is to check whether the opcode is question opcode, but it misses two question opcodes: 'EFI_IFR_REF_OP' and 'EFI_IFR_RESET_BUTTON'. Now add them. Cc: Liming Gao Cc: Eric Dong Contributed-under: TianoCore Contribution

[edk2] [patch 0/2] BaseTools/VfrCompile: Add two new option for VfrCompile

patch 1 is to fix a bug in current code. patch 2 is to add two compile option for VfrCompile. Cc: Liming Gao Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Dandan Bi (2):

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

(adding back our friends on cc) On 1 August 2016 at 12:36, Shi, Steven wrote: >> On 1 August 2016 at 12:16, Shi, Steven wrote: >> >> OK, another example: >> >> >> >> pie.s: >> >> >> >> .globl foo >> >> foo: >> >> pushq n@GOTPCREL(%rip)

Re: [edk2] [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

(Apologies, missed out on this branch of the thread on first pass since I was dropped from cc.) On Sun, Jul 31, 2016 at 11:32:08PM -0700, Jordan Justen wrote: > On 2016-07-31 19:12:03, Tian, Feng wrote: > > I may not speak it clear. Sorry for that. > > > > I saw the patch with commit log

Re: [edk2] [patch] NetworkPkg: Fix assert issue in iSCSI driver

Reviewed-by: Fu Siyuan > -Original Message- > From: Zhang, Lubo > Sent: Monday, August 1, 2016 4:38 PM > To: edk2-devel@lists.01.org > Cc: Fu, Siyuan ; Ye, Ting ; Wu, > Jiaxin > Subject: [patch]

Re: [edk2] [patch] NetworkPkg: Fix assert issue in iSCSI driver

Reviewed-by: Ye Ting -Original Message- From: Zhang, Lubo Sent: Monday, August 01, 2016 4:38 PM To: edk2-devel@lists.01.org Cc: Fu, Siyuan ; Ye, Ting ; Wu, Jiaxin Subject: [patch] NetworkPkg: Fix assert

[edk2] [patch] NetworkPkg: Fix assert issue in iSCSI driver

The bug is caused by using already freed memory. If there is already an attempt and execute 'reconnect -r' command, all the AttemptConfig structure will be freed, but the mCallbackInfo->Current is not configured as null and this pointer will be used again in IScsiFormExtractConfig.

Re: [edk2] [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

On 29 July 2016 at 23:58, Daniil Egranov wrote: > Hi Leif, > > > > On 07/29/2016 11:06 AM, Leif Lindholm wrote: >> >> From: Jeff Brasen >> >> Adds support for the EBC VM for AARCH64 platforms >> >> Submitted on behalf of a third-party: The Linux

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

> On 1 August 2016 at 09:54, Shi, Steven wrote: > >> On 1 August 2016 at 09:19, Shi, Steven > > wrote: > >> >> >> > >> >> >> The fact that it works does not make it safe. Having multiple fixups > >> >> >> for the same symbol

Re: [edk2] [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Hi Feng, For the record, http://opensource.org/licenses/bsd-license.php is the same as http://opensource.org/licenses/BSD-2-Clause. Which is mentioned explicitly under point 5 of the MdeModulePkg Contributions.txt: --- 5. It is preferred that contributions are submitted using the same

Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

On Mon, Aug 01, 2016 at 12:03:06AM -0700, Jordan Justen wrote: > On 2016-07-31 16:52:23, Kinney, Michael D wrote: > > Jordan, > > > > UEFI Drivers distributed as binaries do not need depex sections. > > > > PI modules distributed as binaries do require a .depex binary. > > > > They may require

[edk2] [PATCH v5 5/8] ArmPkg: add prebuilt glue binaries for GCC5 LTO support

GCC in LTO mode interoperates poorly with non-standard libraries that provide implementations of compiler intrinsics such as memcpy/memset or the stack protector entry points. Such libraries need to be built in non-LTO mode, and then referenced explicitly on the linker command line using a

[edk2] [PATCH v5 8/8] BaseTools GCC: introduce GCC5 toolchain to support GCC v5.x in LTO mode

This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and AARCH64. Due to the fact that the GCC project switched to a new numbering scheme where the first digit is now incremented for every major release, the new toolchain is simply called 'GCC5', and is intended to support all GCC v5.x

[edk2] [PATCH v5 6/8] BaseTools GCC: drop GNU notes section from EFI image

Recent versions of GNU ld automatically emit a .notes section into the ELF binary containing a build id. Since this is an allocatable section by default, it will be identified by GenFw as a section that requires PE/COFF conversion, which may cause sections to be moved around unexpectedly. So

[edk2] [PATCH v5 3/8] BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into GCCLD

Before we can make non-backward compatible changes to the GCC build rules regarding the use of the 'gcc' binary as the linker, clone the existing GCC build rules into a 'GCCLD' build rule family, and move the legacy toolchains UNIXGCC, CYGGCC, CYGGCCxASL and ELFGCC over to it. Contributed-under:

[edk2] [PATCH v5 2/8] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note sections

Newer versions of ld automatically emit .gnu.hash and .note.gnu.build-id sections, which are not listed in the linker script, and will end up breaking the build with an allocation conflict, e.g., /usr/bin/aarch64-linux-gnu-ld: section .note.gnu.build-id loaded at

[edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

When building with LTO enabled, the LTO routines infer from the 'hidden' visibility of the _ModuleEntryPoint symbol that its code only needs to be retained if it is referenced internally, and disregards the fact that it is referenced by the entry point field in the ELF metadata. This is arguably

[edk2] [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode

This v5 to introduce GCC5 is now a 8 piece series, including some preparatory cleanup patches that allow all GCC4x and CLANG35 toolchains to switch to using 'gcc' as the linker. This allows us to get rid of the wrapper script to marshall ld arguments in order to make them understandable by gcc,

[edk2] [PATCH v5 1/8] BaseTools CLANG35: drop problematic use-movt and save-temps options

Some versions of Clang fail on every input file when using the -save-temps options, and produces the following heplful error message: :0: error: Undefined temporary symbol Simply dropping the option for CLANG35 is the simplest way around this, since the value of storing .i and .s files is

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

On 1 August 2016 at 09:54, Shi, Steven wrote: >> On 1 August 2016 at 09:19, Shi, Steven >> > wrote: >> >> >> >> >> >> The fact that it works does not make it safe. Having multiple fixups >> >> >> for the same symbol in the

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

> On 1 August 2016 at 09:19, Shi, Steven > > wrote: > >> >> > >> >> The fact that it works does not make it safe. Having multiple fixups > >> >> for the same symbol in the .reloc section is a problem, and so is > >> >> reapplying GOTPCRELX to

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

On 1 August 2016 at 09:19, Shi, Steven wrote: >> >> >> >> The fact that it works does not make it safe. Having multiple fixups >> >> for the same symbol in the .reloc section is a problem, and so is >> >> reapplying GOTPCRELX to places where the original instruction has been

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

> >> > >> The fact that it works does not make it safe. Having multiple fixups > >> for the same symbol in the .reloc section is a problem, and so is > >> reapplying GOTPCRELX to places where the original instruction has been > >> replaced by the linker. > >> > > [Steven]: I still don't understand

[edk2] [PATCH] OvmfPkg: use StatusCode Router and Handler from MdeModulePkg

Use StatusCode Router and Handler from MdeModulePkg instead of IntelFrameworkModulePkg. MdeModulePkg ones follows PI spec to implement StatusCode Router/Handler and provide StatusCode service. It allows the different status code handlers to be registered. IntelFrameworkModulePkg one just

Re: [edk2] [PATCH] add top-level .gitattributes file, dealing with .depex

On 2016-07-31 16:52:23, Kinney, Michael D wrote: > Jordan, > > UEFI Drivers distributed as binaries do not need depex sections. > > PI modules distributed as binaries do require a .depex binary. > They may require a depex, but, as mentioned below, they can also add it directly in the .fdf. As

[edk2] [PATCH] MdePkg: move to 'hidden' visibility for all symbols under GCC/X64

When using GCC to build for X64, we switched to the position independent small code model, which is much more efficient in terms of code generation and runtime relocation footprint, and produces binaries that can execute correctly from any offset. However, the PIC routines are by default geared

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

On 1 August 2016 at 08:13, Shi, Steven wrote: >> >> >> >> I am also concerned about the GOTPCRELX/REX_GOTPCRELX relocations. >> >> Reading the x86_64 ABI docs, it appears that these may refer to >> >> instructions that have been modified by the linker. In that case, how >>

Re: [edk2] [RFC 1/2] MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

On 2016-07-31 19:12:03, Tian, Feng wrote: > I may not speak it clear. Sorry for that. > > I saw the patch with commit log "Submitted on behalf of a > third-party: ". But this is part of "TianoCore Contribution > Agreement 1.0 section 4". > > And the Contributions.txt clearly says "the commit

Re: [edk2] [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

> >> > >> I am also concerned about the GOTPCRELX/REX_GOTPCRELX relocations. > >> Reading the x86_64 ABI docs, it appears that these may refer to > >> instructions that have been modified by the linker. In that case, how > >> do we deal with the relocation? Also, according to the doc, mov > >>

Re: [edk2] [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode

On 1 August 2016 at 04:26, Gao, Liming wrote: > Ard: > My GNU ld (GNU Binutils for Ubuntu) 2.24. Which version you use? > > 1. #pragma GCC visibility push (hidden) , GCC5 with GCC49 tool chain pass. > GCC5 with GCC5 tool chain failure. Here is failure message. > GenFw: