[Steven]: Yes. We could separate it in a new patch. [Steven]: Yes, it is necessary. Even the R_X86_64_64 relocation need to emit the EFI_IMAGE_REL_BASED_DIR64 fixup reloc like below in the original

That was not my point. With your code, how many EFI_IMAGE_REL_BASED_DIR64 fixups are added to the .reloc section for the GOT entry of 'n'? int n; int f () { return n; } int g () { return n; } int h

HI Marvin I found you mention: “If one spends a few hours on FSP, I think it wouldn't be too hard to split the binary and integrate its PEIMs into the host Boot Loader directly, so that the isolated

@Liming: is the issue still reproducible with this change? """ diff --git a/MdePkg/Include/X64/ProcessorBind.h b/MdePkg/Include/X64/ProcessorBind.h index a4aad3e..73cf799 100644 ---

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,

I don't know about banning it, but at least we could wait for someone to make a reasonable argument why they are needed. Even for binary only modules, it looks like the fdf method outlined below is

Jordan, UEFI Drivers distributed as binaries do not need depex sections. PI modules distributed as binaries do require a .depex binary. So I would recommend .depex binary files be treated the same

Thomas, I agree some of them are not supported due to the UEFI OpenSSL configuration, but it doesn't affect those mapping relationship added in the patch. So, I have no strong opinion whether to

I personally prefer to keep the current supported cipher suite for our UEFI-TLS enabling. We can have the full RFC definitions, and platform specific cipher sets for validation now. It's better to

Hi, Leif If I understand correctly, EDKII doesn't allow such BSD license. Correct me if anybody has different opinions. Thanks Feng

Hey Feng, According to the Contributions document, BSD 2-clause is one of the licenses that can be accepted, if the parent license cannot be

I may not speak it clear. Sorry for that. I saw the patch with commit log "Submitted on behalf of a third-party: xxxx". But this is part of "TianoCore Contribution Agreement 1.0 section 4". And the

Fu Siyuan (2): MdeModulePkg: Add missed character in copyright. NetworkPkg: Add missed character in copyright. MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c | 2 +-

Cc: Wu Jiaxin <jiaxin.wu@...> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@...> --- MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Impl.c | 2

Cc: Wu Jiaxin <jiaxin.wu@...> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@...> --- NetworkPkg/Dhcp6Dxe/Dhcp6Io.c | 2 +-

Add Leif's commit log here for better understanding my concern:) "Import the AArch64 EBC implementation from https://source.codeaurora.org/external/server/edk2-blue/ 1/2 does not contain a

Series Reviewed-By: Wu Jiaxin <jiaxin.wu@...> Best Regards! Jiaxin

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

[Steven]: If the above global " n " need GOTPCREL type relocation. It should need only once EFI_IMAGE_REL_BASED_DIR64 fixups in my code. [Steven]: Frankly to say, the x86_64 ABI docs is only good for

Yes, I believe so. I think it would be possible to sort the .reloc section and eliminate duplicates, but doing this correctly is non-trivial in any case. No, that is not what these are for. The