This patch series will add the following definition in the [BuildOptions] section in package DSC files to disable APIs that are deprecated: [BuildOptions] *_*_*_CC_FLAGS = -D

Ard, as usual you rock... Using the GAS .macro syntax this all collapses nicely. I tested it with one assembly function and all the right stuff happens. So the request becomes: can we modify all of

FYI there is a null token \() for GAS which you can use to concatenate a string with a macro argument, e.g., .macro func, x .globl \x .type \x, %function .section .text.\x \x\():

What about GAS macros (.macro / .endm). I prefer those over cpp macros in assembler anyway. The asm dialect is 99% aligned between CLANG and GNU as, so this shouldn't be a problem I think this would

Good point. I will send out a v2 tomorrow

ard, i think you need to have R_X86_64_PLT32 case in WriteRelocations64. without that, i still hit the invalid relocation message.

Ard and Leif, I've been too backlogged to provide a real patchset at this point but wanted to get your approval on this proposal... As you know we have some code size sensitive uncompressed XIP

not directly related but could we add nostdinc too? At least for my platform that works perfectly and it prevents you from accidentally including any libc/libgcc/whatever headers from your

Avoid build errors when including OpensslLib, which may throw undefined reference errors for builtin functions if -fno-builtin is not specified (and it is already set for IA32, X64 and AARCH64) So set

The ARM compiler intrinsics library defines __aeabi_memset() and memset() in the same object, which means that both will be pulled in if either is referenced. The IntrinsicLib in CryptoPkg defines

Building ArmSoftFloatLib with LTO results in errors like .../bin/ld: softfloat.obj: plugin needed to handle lto object .../bin/ld: __aeabi_dcmpge.obj: plugin needed to handle lto object

This series addresses some issues that cause the build to be broken for ARM GCC5 at the moment when including OpensslLib in the build. Ard Biesheuvel (3): ArmPkg/ArmSoftFloatLib: disable LTO build

Reviewed-by: Leif Lindholm <leif.lindholm@...> Pushed (with a tweak to the subject line), thanks!

Reviewed-by: Chao Zhang<chao.b.zhang@...> Thanks & Best regards Chao Zhang

Did you read the elaborate comment block explaining that (and why) it is appropriate to treat R_X86_64_PLT32 as a R_X86_64_PC32 relocation? This is not generally true, but it is true for UEFI since we

OK, it is. But it is a bit not very clear. Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522

Isn't it identical to the code for R_X86_64_PC32?

Hi Ard, I don't see you add below code for case R_X86_64_PLT32. Is it right? *(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ + (mCoffSectionsOffset[Sym->st_shndx] -

For X64/GCC, we use position independent code with hidden visibility to inform the compiler that symbols references are never resolved at runtime, which removes the need for PLTs and GOTs. However, in