When I ask compiler questions to my compiler peeps they sometime answer via: https://godbolt.org. You can pas -emit-llvm, -S, or actually run code all from the webpage. It lets you compare the output

I’ve not tested on ARM yet, so please let me know if it works. I’d like to avoid Python 2.7 support is possible given it is passed its best by date. Thanks did not notice that. Shoot though I fixed th

In this case p ends up in a __DATA__,__const section since &a requires a relocation. I don’t see your bigger point. The compiler is free to implement as it sees fit. Which section some code ends up in

It is a physics problem we can’t fix, so I end up writing some patches to fix other peoples assembler from time to time. The CI building with Xcode helps with this a lot. Sorry I don’t understand what

Sorry I get way to much email….. I’m still trying to wrap my head around the definition of the nasm RODATA_SECTION_NAME. Do we want it to track what ends up in the object file, the native executable,

I forgot I have an Ubuntu VM so we can take a look at an ELF to PE/COFF toolchain example …. So it looks like nasm[1] “does the right thing”(tm) and places a .rodata section in the object file…. But i

The Xcode linker emits a fatal error on X64 for a relocation in the __TEXT section, everything needs to be RIP relative and the compiler does that for free. We generally only run into this for hand co

I think we are saying the same thing. My point is it is possible to use the library API correctly, but likely no one does. Changing the API to a VOID also does not fix every issue, actually it is a dr

Ray, I made a detailed response about Mach-O with Xcode/clang and I don’t think patch works. Not sure if it breaks anything, but it puts things in the .data PE/COFF section. I’m also worried it is bro

An EFI Mach-O file does not contain a .rodata section. A Mach-O contains a __DATA segment that is broken up into sections. For a typical EFI image there are __const, __data, __bss sections in the __DA

MIke, I want to say we had a discussion about this years ago? I don’t remember the outcome. Dereferencing a misaligned pointer is UB (Undefined Behavior) in C [1], but historically x86 compilers have

https://bugzilla.tianocore.org/show_bug.cgi?id=3500 Use efi_debugging.py Python Classes to implement EFI gdb commands: (gdb) help efi Commands for debugging EFI. efi <cmd> List of efi subcommands: efi

https://bugzilla.tianocore.org/show_bug.cgi?id=3500 Use efi_debugging.py Python Classes to implement EFI gdb commands: efi_symbols, guid, table, hob, and devicepath You can attach to any standard gdb

This patch set adds debugging support for gdb and lldb. It also adds generic debugging classes that use a file like object to make it easy to import into any debugger that supports Python. Since these

I also like to think of this in terms on static and dynamic linking. For things that would be statically linked we use EDKII library classes. For dynamic linking we use Protocol/PPI and the required t

I’d guess I’d also ask the why not NewLib? Especially since Red Hat helps out with edk2…. Thanks, Andrew Fish

Reviewed by: Andrew Fish <afish@...>

For our internal repos we set all our targets to build the build.log file for this reason. This is a quick way to find the library class instances in the repo… $ git grep DebugLib -- *.inf | grep LIBR

Marvin, It is useful to remember that there are object file (resolved by the linker), dynamic loading (resolved when the DLL is bound at runtime), and image relocations. In the EFI PE/COFF we only end