<div dir="ltr">Hi,<div><br></div><div>1) Using the system's native compiler and trying to target something that's not the compiler's target is already pretty much undefined. Codegen, compiler + assembler behaviour, runtime libraries can all vary between different targets of the same compiler.</div><div><br></div><div>2) Absolutely not. The compiler's runtime libraries are targeted to the hosted environment and are compiled against the C library. Although this isn't really a problem, since most functions you want to use in a kernel-like environment will only depend on possibly abort() if anything.</div><div><br></div><div>3) No, the paths are not stable and vary between Linux distros even, but there's a way to get the location of libgcc and compiler_rt using "<clang/gcc> -print-libgcc-file-name". Whether that gives you a shared library or static library heavily depends on the distribution...</div><div><br></div><div>I think that maybe "Why are we bringing in so much third-party code to firmware?" is a way better question than "is it feasible to implement all the required builtins?". Why can my firmware speak TLS, and why does it have a whole copy of *OpenSSL*, which is a huge library with a big attack surface and was never written to be run in a firmware/kernel/bare metal environment like UEFI. </div><div><br></div><div>Note: If there's a big need for something like internal TLS I would recommend BearSSL as a very small TLS implementation that was actually written for embedded systems.</div><div><br></div><div>Best regards,</div><div>Pedro<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 28, 2022 at 12:55 AM Andrew Fish via <a href="http://groups.io">groups.io</a> <afish=<a href="mailto:apple.com@groups.io">apple.com@groups.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Very cool idea but …..<div><br></div><div>1) We don’t always use the systems native compiler and sometimes we use a cross compiler so making assumptions about system libs is not always valid.<div><br></div><div>On a Mac with Xcode clang I’ve got full SysV ABI libs (not supper helpful for EFI), but not EFI/MSFT x86_64 ABI. For bonus point i386 has been obsoleted in Xcode.</div><div><div><br></div><div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)">~/work/Compiler/Math</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(159,160,28)"><b>></b></span><span style="font-variant-ligatures:no-common-ligatures">cat hello.c                                </span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">#include <stdio.h></span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">int main(int argc, char **argv)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">{</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">  unsigned long long ulldiv = ((unsigned long long) argc)/3;</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">  // prevent the optimizer to calculate result at build time</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">  printf("ulldiv %lld\n", ulldiv );</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">}</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)">~/work/Compiler/Math</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(159,160,28)"><b>></b></span><span style="font-variant-ligatures:no-common-ligatures">clang hello.c</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="font-family:Helvetica;font-size:12px">Thus I can link Sys V ABI with the wrong calling convention for EFI.</span></span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="font-family:Helvetica;font-size:12px"><br></span></span></div><div style="margin:0px;font-stretch:normal;line-height:normal"><span style="font-variant-ligatures:no-common-ligatures">But for the EFI ABIs not so much….</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)">~/work/Compiler/Math</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(159,160,28)"><b>></b></span><span style="font-variant-ligatures:no-common-ligatures">clang -target x86_64-pc-win32-macho hello.c</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">clang: </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(200,20,201)"><b>warning: </b></span><span style="font-variant-ligatures:no-common-ligatures"><b>unable to find a Visual Studio installation; try running Clang from a developer command prompt [-Wmsvc-not-found]</b></span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><b>hello.c:1:10: </b></span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)"><b>fatal error: </b></span><span style="font-variant-ligatures:no-common-ligatures"><b>'stdio.h' file not found</b></span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">#include <stdio.h></span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(47,180,29)"><span style="font-variant-ligatures:no-common-ligatures"><b>         ^~~~~~~~~</b></span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">1 error generated.</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)">~/work/Compiler/Math</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(159,160,28)"><b>></b></span><span style="font-variant-ligatures:no-common-ligatures">clang -arch i386 hello.c                   </span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/usr/lib/libSystem.tbd (3 slices)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">Undefined symbols for architecture i386:</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">  "_printf", referenced from:</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">      _main in hello-380c0a.o</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">ld: symbol(s) not found for architecture i386</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">clang: </span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)"><b>error: </b></span><span style="font-variant-ligatures:no-common-ligatures"><b>linker command failed with exit code 1 (use -v to see invocation)</b></span></div><div><span style="font-variant-ligatures:no-common-ligatures"><b><br></b></span></div><div><br></div><div>2) Are these system libs architecturally defined to be free standing? Can they make assumptions about the runtime? If so seems like they could do random bad things to make them not work in EFI like a system call or make other assumptions like writing to a magic address to generate a trap. Just inspecting them tells us the implementation, not the architecture of the lib.</div><div><br></div><div>3) Are the paths to these libs architectural or are they arbitrary implementation that is normal abstracted by how the compiler is released? Could some packaging change break the magic paths to libs?</div><div><br></div><div>4) I asked the Xcode/clang team a long time ago what to do for free standing match and they pointed me at some open source implementation of these math libs that had been implemented in C. They did not want us using their libs that shipped with macOS. </div><div><br></div><div><br></div><div>For the GCC/clang tools seems like we are better off just providing the code. </div><div><br></div><div>We have magic for compiler specific inline assembly </div><div><a href="https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/Ia32/GccInline.c" target="_blank">https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/Ia32/GccInline.c</a></div><div><br></div><div>We have magic to abstract some compiler intrinsics today:</div><div><a href="https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLibIntrinsic/IoLibMsc.c" target="_blank">https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLibIntrinsic/IoLibMsc.c</a></div><div><a href="https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c" target="_blank">https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c</a></div><div><br></div><div>While we try to avoid it when at all possible the build system does support doing things differently for different compilers if we have to</div><div><a href="https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf#L38" target="_blank">https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf#L38</a></div><div></div><div><table style="box-sizing:border-box;border-spacing:0px;border-collapse:collapse;color:rgb(36,41,47);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><tbody style="box-sizing:border-box"><tr style="box-sizing:border-box"><td id="gmail-m_3764662340190189359L38" style="box-sizing:border-box;padding:0px 10px;width:50px;min-width:50px;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;line-height:20px;text-align:right;white-space:nowrap;vertical-align:top"></td><td id="gmail-m_3764662340190189359LC38" style="box-sizing:border-box;padding:0px 10px;line-height:20px;vertical-align:top;overflow:visible;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;white-space:pre-wrap">[Sources.IA32]
</td></tr><tr style="box-sizing:border-box"><td id="gmail-m_3764662340190189359L39" style="box-sizing:border-box;padding:0px 10px;width:50px;min-width:50px;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;line-height:20px;text-align:right;white-space:nowrap;vertical-align:top"></td><td id="gmail-m_3764662340190189359LC39" style="box-sizing:border-box;padding:0px 10px;line-height:20px;vertical-align:top;overflow:visible;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;white-space:pre-wrap">  IoLibGcc.c    | GCC
</td></tr><tr style="box-sizing:border-box"><td id="gmail-m_3764662340190189359L40" style="box-sizing:border-box;padding:0px 10px;width:50px;min-width:50px;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;line-height:20px;text-align:right;white-space:nowrap;vertical-align:top"></td><td id="gmail-m_3764662340190189359LC40" style="box-sizing:border-box;padding:0px 10px;line-height:20px;vertical-align:top;overflow:visible;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;white-space:pre-wrap">  IoLibMsc.c    | MSFT
</td></tr><tr style="box-sizing:border-box"><td id="gmail-m_3764662340190189359L41" style="box-sizing:border-box;padding:0px 10px;width:50px;min-width:50px;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;line-height:20px;text-align:right;white-space:nowrap;vertical-align:top"></td><td id="gmail-m_3764662340190189359LC41" style="box-sizing:border-box;padding:0px 10px;line-height:20px;vertical-align:top;overflow:visible;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;white-space:pre-wrap">  IoLib.c
</td></tr><tr style="box-sizing:border-box"><td id="gmail-m_3764662340190189359L42" style="box-sizing:border-box;padding:0px 10px;width:50px;min-width:50px;font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:12px;line-height:20px;text-align:right;white-space:nowrap;vertical-align:top"></td></tr></tbody></table><br></div><div><br></div><div>Thanks,</div><div><br></div><div>Andrew Fish</div><div><br></div><div>PS The compiler still works like you think we just don’t have the libs you might need. </div><div><br></div><div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)">~/work/Compiler/Math</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(159,160,28)"><b>></b></span><span style="font-variant-ligatures:no-common-ligatures">cat i386.c             </span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">typedef unsigned long long UINT64;</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">UINT64</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">main2(int argc, char **argv)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">{</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">  UINT64 ulldiv = ((UINT64) argc)/3;</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">  // prevent the optimizer to calculate result at build time</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">  return  ulldiv;</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">}</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)">~/work/Compiler/Math</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(159,160,28)"><b>></b></span><span style="font-variant-ligatures:no-common-ligatures">clang -arch i386 i386.c -S</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:rgb(180,36,25)">~/work/Compiler/Math</span><span style="font-variant-ligatures:no-common-ligatures;color:rgb(159,160,28)"><b>></b></span><span style="font-variant-ligatures:no-common-ligatures">cat i386.S                </span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">        </span>.section<span style="white-space:pre-wrap">        </span>__TEXT,__text,regular,pure_instructions</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">       </span>.build_version macos, 12, 0<span style="white-space:pre-wrap">     </span>sdk_version 12, 0</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">     </span>.globl<span style="white-space:pre-wrap">  </span>_main2                          ## -- Begin function main2</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">       </span>.p2align<span style="white-space:pre-wrap">        </span>4, 0x90</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">_main2:                                 ## @main2</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">    </span>.cfi_startproc</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">## %bb.0:</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">     </span>pushl<span style="white-space:pre-wrap">   </span>%ebp</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">  </span>.cfi_def_cfa_offset 8</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap"> </span>.cfi_offset %ebp, -8</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">  </span>movl<span style="white-space:pre-wrap">    </span>%esp, %ebp</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">    </span>.cfi_def_cfa_register %ebp</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">    </span>subl<span style="white-space:pre-wrap">    </span>$24, %esp</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">     </span>movl<span style="white-space:pre-wrap">    </span>12(%ebp), %eax</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">        </span>movl<span style="white-space:pre-wrap">    </span>8(%ebp), %eax</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap"> </span>movl<span style="white-space:pre-wrap">    </span>8(%ebp), %ecx</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap"> </span>movl<span style="white-space:pre-wrap">    </span>%ecx, %edx</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">    </span>sarl<span style="white-space:pre-wrap">    </span>$31, %edx</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">     </span>movl<span style="white-space:pre-wrap">    </span>%esp, %eax</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">    </span>movl<span style="white-space:pre-wrap">    </span>%edx, 4(%eax)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap"> </span>movl<span style="white-space:pre-wrap">    </span>%ecx, (%eax)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">  </span>movl<span style="white-space:pre-wrap">    </span>$0, 12(%eax)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">  </span>movl<span style="white-space:pre-wrap">    </span>$3, 8(%eax)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">   </span>calll<span style="white-space:pre-wrap">   </span>___udivdi3</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">    </span>movl<span style="white-space:pre-wrap">    </span>%edx, -4(%ebp)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">        </span>movl<span style="white-space:pre-wrap">    </span>%eax, -8(%ebp)</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">        </span>movl<span style="white-space:pre-wrap">    </span>-8(%ebp), %eax</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">        </span>movl<span style="white-space:pre-wrap">    </span>-4(%ebp), %edx</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">        </span>addl<span style="white-space:pre-wrap">    </span>$24, %esp</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">     </span>popl<span style="white-space:pre-wrap">    </span>%ebp</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">  </span>retl</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures"><span style="white-space:pre-wrap">  </span>.cfi_endproc</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">                                        ## -- End function</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures">.subsections_via_symbols</span></div></div><div><span style="font-variant-ligatures:no-common-ligatures"><br></span></div><div><div>PPS Fun story about ABI differences as the macOS i386 ABI requires 16-byte aligned stack accesses and that is more strict than EFI. Luckily it does not break EFI, but it means you can NOT call macOS code from EFI code. To make the emulator work on macOS I had to write assembly gaskets to align the stacks to make calls between the worlds possible. Not my finest hour but it works….</div><div><a href="https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Ia32/Gasket.S" target="_blank">https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Ia32/Gasket.S</a></div><div><br></div><div>This crazy is an example about how assumptions that are not EFI centric can leak into the generic libs produced for the compiler.</div><div><br></div><div><blockquote type="cite"><div>On Jan 27, 2022, at 2:26 PM, Kilian Kegel <<a href="mailto:KILIAN_KEGEL@OUTLOOK.COM" target="_blank">KILIAN_KEGEL@OUTLOOK.COM</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Hi Gerd,</div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>* On my system the gcc intrinsics are only available as shared library,<br>>   so the "just unpack the lib and use the object files" idea is not<br>>   going to work.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span id="gmail-m_3764662340190189359cid:image002.png@01D81390.22979F10"><D175366159184B98AC9B192EC485505B.png></span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">This little C program makes an unsigned 64Bit division on PC compilers.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Running a 32Bit code generator, it usually invokes an<span> </span><i>intrinsic<span> </span></i>function<i>.<u></u><u></u></i></div><ul type="disc" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">MSFT: __aulldiv()</li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">GCC: __udivdi3()</li></ul><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On my 32Bit Ubuntu standard installation I ran</div><ol start="1" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">cc - Xlinker -Map=static.map hello.c -static</li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">cc  -Xlinker -Map=shared.map hello.c</li></ol><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><i><u></u> <u></u></i></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">The first .OBJ file mentioned in the .MAP file is in both cases:<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>/usr/lib/gcc/i686-linux-gnu/6/libgcc.a(_udivdi3.o)<u></u><u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span id="gmail-m_3764662340190189359cid:image004.png@01D8139D.F9CF1140"><DC03DFFFFFF14308B3A615804A1BF474.png></span><b><u></u><u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u></u> <u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span id="gmail-m_3764662340190189359cid:image003.png@01D8139E.1CD325F0"><377AC53F424C47F794809BA1A5953904.png></span><b><u></u><u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Then for each a.out I did:<u></u><u></u></div><ul type="disc" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">objdump -d a.out > static.dis</li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">objdump -d a.out > shared.dis</li></ul><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">In both cases the intrinsic function is fully linked into the .ELF executable.</div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span id="gmail-m_3764662340190189359cid:image005.png@01D8139E.B11BCFA0"><B5A273DA2C3A4898BAEB0A354C667FE5.png></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>so the "just unpack the lib and use the object files" idea is not<br>>going to work.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">It seems to me that GNU holds the intrinsic functions in a separate library<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">that can be used without any change, and is always correct by definition.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">For Microsoft that is only true when a SDK is installed (INT64.LIB).<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Without SDK the intrinsic functions were included in LIBCMT.LIB and<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">must be isolated manually.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Gerd, can you please doublecheck in your GCC build, if that works:<u></u><u></u></div><ol start="1" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">add a 64Bit div to an x86 PEI module like:</li></ol><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span id="gmail-m_3764662340190189359cid:image007.png@01D813C5.041241A0"><500D8F2283CD4FAE9B0E45647823894A.png></span></div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><ol start="2" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">add<span> </span><b>libgcc.a</b><span> </span>as a search library, adjust the<span> </span><b>conf\tools_def.txt</b><span> </span>like:<u></u><u></u></li></ol><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-family:"Miriam Fixed"">DEBUG_GCCxx_IA32_DLINK_FLAGS   = …predefined parameter …<span> </span><b><span style="color:red">/usr/lib/gcc/i686-linux-gnu/6/libgcc.a<u></u><u></u></span></b></span></div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span>to match your build system<u></u><u></u></span></div><ol start="3" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">build the BIOS<span> </span><u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">if the build gets ready, check the .MAP file<span> </span><span lang="EN">whether it contains <span> </span></span>__udivdi3() or not<u></u><u></u></li></ol><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>* I have my doubts that compiler's builtin libraries are optimized for<br>>   size, so I'd suspect we would see a noticeable size grow from that.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Please check the size of<span> </span><span>__udivdi3()<span> </span></span>and whether the tianocore reimplementation is smaller or not<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">If this works for all build platforms, independently of using the tianocore reimplementation or<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">using the original compiler intrinsics, this is correct location to place the address of the intrinsic library.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">For all optimization modes, operation modes (64Bit/32Bit) the intrinsic library is available for the compiler.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">GNU lists the intrinsics:<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><a href="https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc" style="color:blue;text-decoration:underline" target="_blank">https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html#Libgcc</a><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u>The intrinsic library belongs to the compiler not to the build system.<u></u><u></u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u>If the build system changes from EDK2 to VS2022/MSBUILD, the compiler<u></u><u></u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u>expects the same intrinsic library.<u></u><u></u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u></u> <u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>Leave the intrinsic restrictions behind and just provide<span> </span><i><u>all required intrinsics</u></i><span> </span>the compiler needs<u></u><u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>to fulfil the C-Standard!<u></u><u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span>Thanks a lot,<u></u><u></u></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span>Kilian<u></u><u></u></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><a href="https://github.com/tianocore/edk2-staging/tree/CdePkg#cdepkgblog" style="color:blue;text-decoration:underline" target="_blank">https://github.com/tianocore/edk2-staging/tree/CdePkg#cdepkgblog</a><span><u></u><u></u></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif;border:none;padding:0in"><b>From:<span> </span></b><a href="mailto:kraxel@redhat.com" style="color:blue;text-decoration:underline" target="_blank">kraxel@redhat.com</a><br><b>Sent:<span> </span></b>Wednesday, January 26, 2022 12:02 PM<br><b>To:<span> </span></b><a href="mailto:pedro.falcato@gmail.com" style="color:blue;text-decoration:underline" target="_blank">Pedro Falcato</a><br><b>Cc:<span> </span></b><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">edk2-devel-groups-io</a>;<span> </span><a href="mailto:michael.d.kinney@intel.com" style="color:blue;text-decoration:underline" target="_blank">Kinney, Michael D</a>;<span> </span><a href="mailto:kilian_kegel@outlook.com" style="color:blue;text-decoration:underline" target="_blank">Kilian Kegel</a>;<span> </span><a href="mailto:jiewen.yao@intel.com" style="color:blue;text-decoration:underline" target="_blank">Yao, Jiewen</a>;<span> </span><a href="mailto:sean.brogan@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Sean Brogan</a>;<span> </span><a href="mailto:Bret.Barkelew@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Bret Barkelew</a>;<span> </span><a href="mailto:jian.j.wang@intel.com" style="color:blue;text-decoration:underline" target="_blank">Wang, Jian J</a>;<span> </span><a href="mailto:guomin.jiang@intel.com" style="color:blue;text-decoration:underline" target="_blank">Jiang, Guomin</a>;<span> </span><a href="mailto:ppolawsk@redhat.com" style="color:blue;text-decoration:underline" target="_blank">Pawel Polawski</a>;<span> </span><a href="mailto:xiaoyux.lu@intel.com" style="color:blue;text-decoration:underline" target="_blank">Lu, XiaoyuX</a><br><b>Subject:<span> </span></b>Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0</div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif">  Hi,<br><br>> I think adding intrinsic libraries is a mixed bag, for the following<br>> reasons:<br>><span> </span><br>> 1) The intrinsic libraries are completely internal to the compilers.<br>> Breaking down that toolchain/code barrier is not a good idea if we want the<br>> project to compile using a good variety of compilers. The API is unstable<br>> (as it's internal to the compiler + version) and sometimes undocumented;<br>> while in reality the ABI doesn't really change (at least in the LLVM/GCC<br>> world, not sure about the other compilers), it's something to consider.<br><br>Yes.  But apparently there is no way around them.  We have them for arm.<br>We have them for openssl.  IntelUndiPkg in edk2-staging has some too<br>(see IntelUndiPkg/LibC).  And I wouldn't be surprised if there are more<br>cases ...<br><br>Having a policy to outlaw Intrinsics, but then hand out exceptions left<br>and right doesn't look like a good idea to me.  I think we should revisit<br>that and accept that there simply is no way around Intrinsics in some<br>cases.<br><br>I think it makes sense to consolidate all the Intrinsics we have, i.e.<br>move them over to MdePkg, make everybody use that, so we have only a<br>single version to maintain.<br><br>I think it also makes sense to restrict Intrinsics to the cases where we<br>have no other option, to keep them as small as possible and also make it<br>as easy as possible to maintain them.<br><br>> 2) Linking the compiler's builtin libraries would fix our issues, except<br>> that it doesn't work in cases where object files are tagged with ABI (such<br>> as hard FP vs soft FP).<br><br>Also:<br><br> * On my system the gcc intrinsics are only available as shared library,<br>   so the "just unpack the lib and use the object files" idea is not<br>   going to work.<br><br> * I have my doubts that compiler's builtin libraries are optimized for<br>   size, so I'd suspect we would see a noticeable size grow from that.<br><br> * I'd very much prefer to continue with the current approach to have<br>   source code for the Intrinsics we need.  In case we run into trouble<br>   things tend to be much easier to fix when you have the source code at<br>   hand.  That's actually part of the open source success story.<br><br>take care,<br>  Gerd<u></u><u></u></p><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Sent from<span> </span><a href="https://go.microsoft.com/fwlink/?LinkId=550986" style="color:blue;text-decoration:underline" target="_blank">Mail</a><span> </span>for Windows</div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in"><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif;border:none;padding:0in"><b>From:<span> </span></b><a href="mailto:KILIAN_KEGEL@OUTLOOK.COM" style="color:blue;text-decoration:underline" target="_blank">Kilian Kegel</a><br><b>Sent:<span> </span></b>Tuesday, January 25, 2022 09:06 PM<br><b>To:<span> </span></b><a href="mailto:michael.d.kinney@intel.com" style="color:blue;text-decoration:underline" target="_blank">Kinney, Michael D</a>;<span> </span><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">devel@edk2.groups.io</a>;<span> </span><a href="mailto:kraxel@redhat.com" style="color:blue;text-decoration:underline" target="_blank">kraxel@redhat.com</a>;<span> </span><a href="mailto:jiewen.yao@intel.com" style="color:blue;text-decoration:underline" target="_blank">Yao, Jiewen</a>;<span> </span><a href="mailto:sean.brogan@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Sean Brogan</a>;<span> </span><a href="mailto:Bret.Barkelew@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Bret Barkelew</a><br><b>Cc:<span> </span></b><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">devel@edk2.groups.io</a>;<span> </span><a href="mailto:jian.j.wang@intel.com" style="color:blue;text-decoration:underline" target="_blank">Wang, Jian J</a>;<span> </span><a href="mailto:guomin.jiang@intel.com" style="color:blue;text-decoration:underline" target="_blank">Jiang, Guomin</a>;<span> </span><a href="mailto:ppolawsk@redhat.com" style="color:blue;text-decoration:underline" target="_blank">Pawel Polawski</a>;<span> </span><a href="mailto:xiaoyux.lu@intel.com" style="color:blue;text-decoration:underline" target="_blank">Lu, XiaoyuX</a><br><b>Subject:<span> </span></b>Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0</div></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Hi Mike,<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">thank you for your explanation. I understand all the technical aspects.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">But let me go into the details of my approach, that skips step 2) to 5)<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">and adds step 1.5)<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>I think in practice, the intrinsic APIs we are seeing from use<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>of C code from submodules is a very limited set that do not<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>change across compiler releases,<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I totally agree. E.g INT64.LIB is the same since 2004 (WinXP DDK).<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">But my perspective is different anyway:<u></u><u></u></div><ol start="1" type="a" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">an intrinsic library<span> </span><b><i>belongs</i></b><span> </span>to a particular<span> </span><b>compiler/linker couple      <span> </span></b><u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u>an intrinsic library<span> </span><b><i>does not belong</i></b><span> </span>to a<span> </span><b>UEFI</b><span> </span><b>tianocore</b><span> </span>or<span> </span><b>commercial BIOS</b><span> </span><b>feature set</b><span> </span>and should be managed<u></u><u></u></u></li></ol><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><u>outside from any EDK2 specific build description (.INF, .DSC)<u></u><u></u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Let’s assume there is a C  build environment fully installed, e.g. Microsoft VS2022, on an EDK2 build machine<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">and all legal aspects were fulfilled.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">In that case the advanced developer is able to locate the library, that holds the intrinsic functions<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">(intrinsic .OBJ modules) we needed to extract. (simply by checking the .MAP of a 32bit executable<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">that pulls in the particular intrinsics)<span> </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">This is step 1)<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>One of the challenges is that compilers are allowed to add/remove/modify intrinsic APIs<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>across compiler releases.  We would need to define a solution that will work if there are<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>these types of changes, which would potentially mean a different instance of the intrinsic<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">>library for each tool chain tag. <span> </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Here comes step 1.5):<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">In case of Microsoft build it is LIBCMT.LIB that can be found when walking through the<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">LIB environment string.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">It is easy to extend<span> </span><b>EDKSETUP.BAT</b><span> </span>to generate<span> </span><b>MSFTINTRINx86-32.LIB<span> </span></b>each time<b>:<u></u><u></u></b></div><ol start="1" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">locate LIBCMT.LIB<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">extract the identified .OBJ modules from step 1: “<i>LIB.EXE /extract:full_path_name.obj /out:name.obj LIBCMT.LIB</i>”<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">bind extracted .OBJ to the<span> </span><b>MSFTINTRINx86-32.LIB:<span> </span></b><i>“LIB.EXE *.obj /out<b>:%CONF_PATH%</b></i><b>\<i>MSFTINTRINx86-32.lib</i></b><i>”</i><u></u><u></u></li></ol><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Now<span> </span><b>MSFTINTRINx86-32.LIB<span> </span></b>is located in<b><span> </span></b> the<span> </span><b>conf</b><span> </span>directory.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Adjust the<span> </span><b>DLINK_FLAGS</b><span> </span>in<span> </span><b>tools_def.txt</b><span> </span>to hold<span> </span><b>MSFTINTRINx86-32.LIB<span> </span></b>as a search library:<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-family:"Miriam Fixed""><u></u> <u></u></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-family:"Miriam Fixed"">  DEBUG_VS2015_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /DEBUG<span> </span><b><span style="color:red">%CONF_PATH%\MSFTINTRINx86-32.LIB<u></u><u></u></span></b></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-family:"Miriam Fixed""><u></u> <u></u></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-family:"Miriam Fixed"">RELEASE_VS2015_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /MERGE:.rdata=.data<span> </span><b><span style="color:red">%CONF_PATH%\MSFTINTRINx86-32.LIB<u></u><u></u></span></b></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-family:"Miriam Fixed";color:red"><u></u> <u></u></span></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">From now on the intrinsics are available for all 32Bit components.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-family:"Miriam Fixed""><u></u> <u></u></span></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">With that procedure it is<span> </span><b><u>guaranteed by design</u></b>, that the intrinsics are<span> </span><b><u>always available and match a particular compiler/linker release</u></b>.<u></u><u></u></div><ul type="disc" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">it saves storage space since source code or binary modules don’t need to be kept<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">because they are not kept, they don’t need maintainance<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">no one needs to understand and document (in math details) the internals and the interface<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">no one needs to test for the math functions, as it is necessary for tianocore re-implementations<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">the compiler vendor itself is in charge in a court case<u></u><u></u></li></ul><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">The script below is a demonstration of the above arguments. It additionally adds memcpy() and memcmp() to MSFTINTRINx86-32.LIB,<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">that the compiler sometimes needs, depending on optimization style, array size, instruction set, whatsoever …<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span id="gmail-m_3764662340190189359cid:image001.png@01D81389.F76DB8C0"><A1B2261BD5014BBF968AF0AA25EF9349.png></span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I have checked some more .OBJ from LIBCMT.LIB and some of them (ftol3.obj to get __ltod3()<span> </span><i>long to double<span> </span></i>needed for difftime())<span> </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">seem not to be space optimized for BIOS usage, because the ftol3.obj holds multiple functions<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">(and so violates the ODR one definition rule).<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">But also such cases could be handled automatically by a script (I wrote a C program < 200 lines)<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">that disassembles (using Microsoft DUMPBIN.EXE) the .OBJ, splits by simple text processing into<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">single-function-.ASM-files that could be assembled back to multiple .OBJ of smaller code size.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u>For this approach compiler, library manager, disassembler (DUMPBIN, OBJDUMP) were needed,<u></u><u></u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u>that are available on all build machines by definition.<u></u><u></u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Best regards<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Kilian<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>From:<span> </span></b><a href="mailto:michael.d.kinney@intel.com" style="color:blue;text-decoration:underline" target="_blank">Kinney, Michael D</a><br><b>Sent:<span> </span></b>Monday, January 24, 2022 06:28 PM<br><b>To:<span> </span></b><a href="mailto:kilian_kegel@outlook.com" style="color:blue;text-decoration:underline" target="_blank">Kilian Kegel</a>;<span> </span><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">devel@edk2.groups.io</a>;<span> </span><a href="mailto:kraxel@redhat.com" style="color:blue;text-decoration:underline" target="_blank">kraxel@redhat.com</a>;<span> </span><a href="mailto:jiewen.yao@intel.com" style="color:blue;text-decoration:underline" target="_blank">Yao, Jiewen</a>;<span> </span><a href="mailto:sean.brogan@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Sean Brogan</a>;<span> </span><a href="mailto:Bret.Barkelew@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Bret Barkelew</a>;<span> </span><a href="mailto:michael.d.kinney@intel.com" style="color:blue;text-decoration:underline" target="_blank">Kinney, Michael D</a><br><b>Cc:<span> </span></b><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">devel@edk2.groups.io</a>;<span> </span><a href="mailto:jian.j.wang@intel.com" style="color:blue;text-decoration:underline" target="_blank">Wang, Jian J</a>;<span> </span><a href="mailto:guomin.jiang@intel.com" style="color:blue;text-decoration:underline" target="_blank">Jiang, Guomin</a>;<span> </span><a href="mailto:ppolawsk@redhat.com" style="color:blue;text-decoration:underline" target="_blank">Pawel Polawski</a>;<span> </span><a href="mailto:xiaoyux.lu@intel.com" style="color:blue;text-decoration:underline" target="_blank">Lu, XiaoyuX</a><br><b>Subject:<span> </span></b>RE: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Hi Kilian,<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">I am in favor of an intrinsic lib to improve the EDK II development environment.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">This has already been done for ARM compilers.  The solution should mirror that approach.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">It would be best if we had source code (either in the edk2 repo or through a submodule) for<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">the required intrinsic APIs.  If source code is not possible and we have to use a binary, then<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">that must be accessed through a submodule.  The edk2 repo does not host binaries.  We use<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">repos such as edk2-non-osi for binaries.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">We also have to provide a solution that works with supported compilers (VS, GCC, CLANG, XCODE).<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">One of the challenges is that compilers are allowed to add/remove/modify intrinsic APIs<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">across compiler releases.  We would need to define a solution that will work if there are<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">these types of changes, which would potentially mean a different instance of the intrinsic<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">library for each tool chain tag.  I think in practice, the intrinsic APIs we are seeing from use<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">of C code from submodules is a very limited set that do not change across compiler releases,<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">so the maintenance of these intrinsic libs would be manageable.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">If we go down the source code path, we can break it up into the following tasks:<u></u><u></u></div><ol start="1" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Identify the specific subset of intrinsic APIs from each compiler that is required for the edk2 use cases. <u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Obtain the function prototype and full documentation for each intrinsic API to support implementation and unit tests.<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Implement the APIs for all compilers.<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Implement unit tests for all APIs for all compilers using UnitTestFrameworkPkg unit tests.<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Update MdeLibs.dsc.inc with the NULL instances for the intrinsic libs<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Remove intrinsic APIs from EDK II modules that currently maintain their own implementations of intrinsic APIs.<u></u><u></u></li></ol><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Best regards,<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Mike<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>From:</b><span> </span>Kilian Kegel <<a href="mailto:kilian_kegel@outlook.com" style="color:blue;text-decoration:underline" target="_blank">kilian_kegel@outlook.com</a>><span> </span><br><b>Sent:</b><span> </span>Monday, January 24, 2022 8:25 AM<br><b>To:</b><span> </span><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">devel@edk2.groups.io</a>; Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com" style="color:blue;text-decoration:underline" target="_blank">michael.d.kinney@intel.com</a>>;<span> </span><a href="mailto:kraxel@redhat.com" style="color:blue;text-decoration:underline" target="_blank">kraxel@redhat.com</a>; Yao, Jiewen <<a href="mailto:jiewen.yao@intel.com" style="color:blue;text-decoration:underline" target="_blank">jiewen.yao@intel.com</a>>; Sean Brogan <<a href="mailto:sean.brogan@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">sean.brogan@microsoft.com</a>>; Bret Barkelew <<a href="mailto:Bret.Barkelew@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Bret.Barkelew@microsoft.com</a>><br><b>Cc:</b><span> </span><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">devel@edk2.groups.io</a>; Wang, Jian J <<a href="mailto:jian.j.wang@intel.com" style="color:blue;text-decoration:underline" target="_blank">jian.j.wang@intel.com</a>>; Jiang, Guomin <<a href="mailto:guomin.jiang@intel.com" style="color:blue;text-decoration:underline" target="_blank">guomin.jiang@intel.com</a>>; Pawel Polawski <<a href="mailto:ppolawsk@redhat.com" style="color:blue;text-decoration:underline" target="_blank">ppolawsk@redhat.com</a>>; Lu, XiaoyuX <<a href="mailto:xiaoyux.lu@intel.com" style="color:blue;text-decoration:underline" target="_blank">xiaoyux.lu@intel.com</a>><br><b>Subject:</b><span> </span>RE: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">The 64-bit integer math intrinsics and other intrinsic<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">problems could be solved easily for ever:<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><ol start="1" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Putting all .OBJ files together from LIBCMT.H or INT64.LIB (for ll*.obj and ull*.obj only)<u></u><u></u></li></ol><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif;text-indent:0.5in">ltod3.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">ftol2.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">lldiv.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">lldvrm.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">llmul.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">llrem.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">llshl.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">llshr.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">ulldiv.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">ulldvrm.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">ullrem.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">ullshr.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">memcmp.obj</div><div style="margin:0in 0in 0in 1in;font-size:11pt;font-family:Calibri,sans-serif">memcpycpy.obj</div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">                and adjust for usability in EDK2 (remove / solve further internal dependencies or rewrite “*cpy” and “*cmp” functions)<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif;text-indent:0.5in">This is already done in IntrinsicLib.lib for some of the above functions, just complete this task!<u></u><u></u></div><ol start="2" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Put all the .OBJ into a e.g.<span> </span><b>edk2\Conf \“MSFTINTRINx86-32<compilerversion>.lib”</b><u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>Update the MSFT_DEF.txt tool chain definition path</b><u></u><u></u></li></ol><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">DEBUG_*_IA32_DLINK_FLAGS     = %CONF_PATH%\<b><span> </span>MSFTINTRINx86-32<compilerversion>.lib</b></div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">RELEASE_*_IA32_DLINK_FLAGS   = %CONF_PATH%\<b><span> </span>MSFTINTRINx86-32<compilerversion>.lib</b></div><ol start="4" type="1" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Resolve build conflicts with other existing intrinsic libraries from CryptoPkg, RedfishPkg… – remove these libraries<u></u><u></u></li></ol><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u>From now on all existing 32Bit components have access to their own compiler intrinsics without</u></b><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><u>touching any .INF file and the problem is instantly gone.</u></b><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Please do the same for<span> </span><u></u><u></u></div><ul type="disc" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>GCCINTRINx86-32<compilerversion>.lib</b><u></u><u></u></li></ul><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>Leave the intrinsic restrictions behind and just provide<span> </span><i><u>all required intrinsics</u></i><span> </span>the compiler needs<u></u><u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>to fulfil the C-Standard!<u></u><u></u></b></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">UEFI shall conform the execution environment described in the C Specification<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><a href="https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1256.pdf%23page%3D23&data=04%7C01%7C%7C1db233037ffb4811299008d9df47ba42%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637786321422685738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NuCQGfgDshlvQOKAQerAQaALk11LZA7YKY4eqSwotDg%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=23</a><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">and shall not try to create a new restricted “UEFI execution environment”<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">that currently prohibits some “expressions” (shift << >> , divide / % ) on some “data types” (64bit “long long”)<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">but maybe in the future will prohibit some more “expressions” (logical AND &&, relational-expression < >) on<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">still speculative “data types” (e.g. a 128bit “extended long”) or just because a new compiler<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">(version) with some new optimization(ultra slow)/security(specdown/meltre) capabilities introduces<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">some new intrinsic functions.<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Who knows…<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">In contrast to:<u></u><u></u></div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">“I think we shouldn't add any intrinsics unless we are absolutely forced</div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">to. I do agree however that, for those intrinsics that we cannot at all</div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">avoid reimplementing, we should at least collect them in a common</div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">library.</div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">(In theory, I can also imagine reimplementing all possible intrinsics</div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">*if* the edk2 coding style spec / requirements are updated in parallel,</div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">permitting all new code to universally rely on the intrinsics, rather</div><div style="margin:0in 0in 0in 0.5in;font-size:11pt;font-family:Calibri,sans-serif">than the BaseLib / BaseMemoryLib functions.)”</div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif;text-indent:0.5in"><a href="https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D1516%23c2&data=04%7C01%7C%7C1db233037ffb4811299008d9df47ba42%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637786321422685738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TV9hIhMuhINFVj8PSOQzMnGiknw3HO5zKm7ub5%2BcDow%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">https://bugzilla.tianocore.org/show_bug.cgi?id=1516#c2</a><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">This mindset violates edk2 coding style spec too:<span> </span><u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><a href="https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2-docs.gitbook.io%2Fedk-ii-c-coding-standards-specification%2F2_guiding_principles&data=04%7C01%7C%7C1db233037ffb4811299008d9df47ba42%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637786321422685738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QVHxAAGiXywPxVI4wKzBtvbyfW16qvigghS1uwkIIcg%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/2_guiding_principles</a><u></u><u></u></div><ul type="disc" style="margin-bottom:0in;margin-top:0in"><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Maintainability<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Extensibility<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Intellectual manageability<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Portability<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Reusability<u></u><u></u></li><li style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Standard techniques<u></u><u></u></li></ul><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Have fun,<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Kilian<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b>From:<span> </span></b><a href="mailto:michael.d.kinney@intel.com" style="color:blue;text-decoration:underline" target="_blank">Michael D Kinney</a><br><b>Sent:<span> </span></b>Friday, January 21, 2022 05:39 PM<br><b>To:<span> </span></b><a href="mailto:kraxel@redhat.com" style="color:blue;text-decoration:underline" target="_blank">kraxel@redhat.com</a>;<span> </span><a href="mailto:jiewen.yao@intel.com" style="color:blue;text-decoration:underline" target="_blank">Yao, Jiewen</a>;<span> </span><a href="mailto:sean.brogan@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Sean Brogan</a>;<span> </span><a href="mailto:Bret.Barkelew@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">Bret Barkelew</a>;<span> </span><a href="mailto:michael.d.kinney@intel.com" style="color:blue;text-decoration:underline" target="_blank">Kinney, Michael D</a><br><b>Cc:<span> </span></b><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">devel@edk2.groups.io</a>;<span> </span><a href="mailto:jian.j.wang@intel.com" style="color:blue;text-decoration:underline" target="_blank">Wang, Jian J</a>;<span> </span><a href="mailto:guomin.jiang@intel.com" style="color:blue;text-decoration:underline" target="_blank">Jiang, Guomin</a>;<span> </span><a href="mailto:ppolawsk@redhat.com" style="color:blue;text-decoration:underline" target="_blank">Pawel Polawski</a>;<span> </span><a href="mailto:xiaoyux.lu@intel.com" style="color:blue;text-decoration:underline" target="_blank">Lu, XiaoyuX</a><br><b>Subject:<span> </span></b>Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0<u></u><u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif">Comments below.<br><br>Mike<br><br>> -----Original Message-----<br>> From:<span> </span><a href="mailto:kraxel@redhat.com" style="color:blue;text-decoration:underline" target="_blank">kraxel@redhat.com</a><span> </span><<a href="mailto:kraxel@redhat.com" style="color:blue;text-decoration:underline" target="_blank">kraxel@redhat.com</a>><br>> Sent: Friday, January 21, 2022 12:31 AM<br>> To: Yao, Jiewen <<a href="mailto:jiewen.yao@intel.com" style="color:blue;text-decoration:underline" target="_blank">jiewen.yao@intel.com</a>><br>> Cc:<span> </span><a href="mailto:devel@edk2.groups.io" style="color:blue;text-decoration:underline" target="_blank">devel@edk2.groups.io</a>; Kinney, Michael D <<a href="mailto:michael.d.kinney@intel.com" style="color:blue;text-decoration:underline" target="_blank">michael.d.kinney@intel.com</a>>; Wang, Jian J <<a href="mailto:jian.j.wang@intel.com" style="color:blue;text-decoration:underline" target="_blank">jian.j.wang@intel.com</a>>; Jiang, Guomin<br>> <<a href="mailto:guomin.jiang@intel.com" style="color:blue;text-decoration:underline" target="_blank">guomin.jiang@intel.com</a>>; Pawel Polawski <<a href="mailto:ppolawsk@redhat.com" style="color:blue;text-decoration:underline" target="_blank">ppolawsk@redhat.com</a>>; Lu, XiaoyuX <<a href="mailto:xiaoyux.lu@intel.com" style="color:blue;text-decoration:underline" target="_blank">xiaoyux.lu@intel.com</a>><br>> Subject: Re: [edk2-devel] [PATCH 00/24] CryptoPkg/openssl: update openssl submodule to v3.0<br>><span> </span><br>> > > No changes in SEC and PEI.<br>> > [Jiewen] Do you mean the Crypto consumer in PEI has no size difference? Such as<br>> ><span> </span><a href="https://github.com/tianocore/edk2/tree/master/SecurityPkg/Tcg/Tcg2Pei" style="color:blue;text-decoration:underline" target="_blank">https://github.com/tianocore/edk2/tree/master/SecurityPkg/Tcg/Tcg2Pei</a><span> </span>,<br>> ><span> </span><a href="https://github.com/tianocore/edk2/tree/master/SecurityPkg/FvReportPei" style="color:blue;text-decoration:underline" target="_blank">https://github.com/tianocore/edk2/tree/master/SecurityPkg/FvReportPei</a><span> </span>,<br>> ><span> </span><a href="https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg/Universal/RecoveryModuleLoadPei" style="color:blue;text-decoration:underline" target="_blank">https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg/Universal/RecoveryModuleLoadPei</a><span> </span>linking<br>><span> </span><a href="https://github.com/tianocore/edk2/tree/master/SecurityPkg/Library/FmpAuthenticationLibRsa2048Sha256" style="color:blue;text-decoration:underline" target="_blank">https://github.com/tianocore/edk2/tree/master/SecurityPkg/Library/FmpAuthenticationLibRsa2048Sha256</a>.<br>><span> </span><br>> PEI has this (OvmfIa32X64Pkg build):<br>><span> </span><br>>     7062 TpmMmioSevDecryptPei<br>>     7830 StatusCodeHandlerPei<br>>     7902 ReportStatusCodeRouterPei<br>>     8470 FaultTolerantWritePei<br>>     9734 SmmAccessPei<br>>    11206 Tcg2ConfigPei<br>>    11842 PeiVariable<br>>    14730 Tcg2PlatformPei<br>>    17274 TcgPei<br>>    18438 S3Resume2Pei<br>>    18682 DxeIpl<br>>    18938 PcdPeim<br>>    38014 CpuMpPei<br>>    39554 PlatformPei<br>>    45050 PeiCore<br>>    49274 Tcg2Pei<br>><span> </span><br>> No size change for Tcg2Pei.<br>><span> </span><br>> The other modules are not there.  Seems they are related to firmware<br>> updates.  We don't have that on ovmf as we can simply update the<br>> firmware image files on the host machine ...<br>><span> </span><br>> Is there some target I could use to test-build those modules?<br>><span> </span><br>> > > INFO - OpensslLibCrypto.lib(rsa_lib.obj) : error LNK2001: unresolved external<br>> > > symbol __allmul<br>> > > INFO - OpensslLibCrypto.lib(rsa_lib.obj) : error LNK2001: unresolved external<br>> > > symbol __aulldiv<br>> > > INFO - OpensslLibCrypto.lib(bio_print.obj) : error LNK2001: unresolved external<br>> > > symbol __aulldvrm<br>> > > INFO - OpensslLibCrypto.lib(bio_print.obj) : error LNK2001: unresolved external<br>> > > symbol __ftol2_sse<br>> > ><br>> > > Those symbols look like they reference helper functions to do 64bit math<br>> > > on 32bit architecture.  Any hints how to fix that?<br>> > [Jiewen] Please add them to<span> </span><a href="https://github.com/tianocore/edk2/tree/master/CryptoPkg/Library/IntrinsicLib" style="color:blue;text-decoration:underline" target="_blank">https://github.com/tianocore/edk2/tree/master/CryptoPkg/Library/IntrinsicLib</a><br>><span> </span><br>> Any hints where I could get them?  Given this happens on windows builds<br>> it's probably somewhere in the microsoft standard C library?  Is that<br>> available as open source somewhere?<br><br>Sean and Bret may be able to help with these.<br><br>There is also a BZ on this topic.<br><br><a href="https://bugzilla.tianocore.org/show_bug.cgi?id=1516" style="color:blue;text-decoration:underline" target="_blank">https://bugzilla.tianocore.org/show_bug.cgi?id=1516</a><br><br>><span> </span><br>> > > (3) Some NOOPT builds are failing due to the size growing ...<br>> > [Jiewen] Size becomes big challenge...<br>> > Have you tried to use<span> </span><a href="https://github.com/tianocore/edk2/tree/master/CryptoPkg/Driver" style="color:blue;text-decoration:underline" target="_blank">https://github.com/tianocore/edk2/tree/master/CryptoPkg/Driver</a><span> </span>solution?<br>><span> </span><br>> Seems the idea is to have only one openssl copy in the dxe image by<br>> calling a protocol instead of linking a lib.  Makes sense.<br>><span> </span><br>> Is this documented somewhere?  Is there some easy way to use that as<br>> drop-in replacement?  Or do we have to change all crypto users to call<br>> the driver instead of linking the lib?<br>><span> </span><br>> take care,<br>>   Gerd<br><br><br><u></u><u></u></p><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><p class="MsoNormal" style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"></p><div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><span id="gmail-m_3764662340190189359cid:3CCA30C7-3FF4-49FC-8476-6FB6F8C5CF3F"><shared.dis></span><span id="gmail-m_3764662340190189359cid:485E471A-D4CA-495F-BC18-87394925DFEE"><shared.map></span><span id="gmail-m_3764662340190189359cid:BC2577A9-90BA-4008-AFF1-30F6325897AF"><static.dis></span><span id="gmail-m_3764662340190189359cid:8576211A-0659-4AFA-94B4-6B6D362535C7"><static.map></span></div></blockquote></div><br></div></div></div></div></div>


  

<p></p><p></p></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Pedro Falcato</div></div>


 <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr>   Groups.io Links:<p>   You receive all messages sent to this group.    <p> <a target="_blank" href="https://edk2.groups.io/g/devel/message/86141">View/Reply Online (#86141)</a> |    |  <a target="_blank" href="https://groups.io/mt/87479913/1813853">Mute This Topic</a>  | <a href="https://edk2.groups.io/g/devel/post">New Topic</a><br>    <a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> |  <a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a>  [edk2-devel-archive@redhat.com]<br> <div width="1" style="color:white;clear:both">_._,_._,_</div>