Andrew Fish

On Mar 24, 2021, at 8:56 AM, Hernandez Miramontes, Jose Miguel <> wrote:

yes, but if the section is not removed debugger would be able to find the debug symbols. Like how it happens with PDB files.
But gdb has no idea that the PE/COFF image exists in some random memory location. So you are going to have to do an ‘add-symbol-file <filename> -o offset` [1] to even let gdb know about your image. If you are not planning on using add-symbol-file what are you planning to use? If the gdb was PE/COFF aware it could load symbols its self if you point it at the PE/COFF?

We could leave the symbols in the binaries, but it will consume more space. Space in the SPI is usually a constrain
In PE/COFF the debug directory entry points to the external symbol file and with works for Windows/Linux/macOS. Conceptually if gdb knows about PE/COFF you should be able to just point gdb start of the image and it could load symbols. But I don’t know of a gdb command that can do that.

I am just wondering if it is possible to fix this so that the section is there in the final efi.
If I were to try it, where would I start?
GenFw is converting ELF to PE/COFF and it is quite brittle and intertwined. I’d insert any new section at the end as you don’t want to break relative offsets between text and data etc. If GenFw sees the image is an ELF file it will automatically attempt to convert it to PE/COFF [1]. That calls ConvertElf() [3] and then that calls the Elf32 or Elf64 functions. As I mentioned if you look closely [4] there are a lot of intertwined assumptions, so if you try to add a new section best to do it to the end of the PE/COFF.

If you have a better strategy than add-symbol-file please share with the community. I ask as it kind of seems if gdb knows enough about PE/COFF to find your magic section, it would know enough to parse the standard PE/COFF Debug Directory Entry. Regardless just having to point at the PE/COFF load address would be somewhat simpler than also having to decode the Debug Directory Entry in a script.

I don’t know much about gdb and your magic section, but I’ve got clang working with mach-O via lldb so I can help answer generic edk2 or PE/COFF questions about how to write debugger scripts, so feel free to ask questions on the list.






Andrew Fish

Jose Miguel Hernandez Miramontes
BIOS Engineer <>
+1 (512) 362-1230
Intel Corporation

-----Original Message-----
From: Ard Biesheuvel < <>>
Sent: Wednesday, March 24, 2021 10:26 AM
To: Laszlo Ersek < <>>
Cc: <>; Hernandez Miramontes, Jose Miguel < <>>; Feng, Bob C < <>>; Saucedo Tejada, Genaro < <>>; Ortiz Garcia, Jorge E < <>>; Ard Biesheuvel (TianoCore) < <>>
Subject: Re: [edk2-discuss]

On Wed, 24 Mar 2021 at 16:18, Laszlo Ersek <> wrote:


On 03/24/21 02:49, Hernandez Miramontes, Jose Miguel wrote:

Is anyone familiar with this file?
I would like to understand more what it does and why it is needed.

When looking at the .efi output of genfw, it seems the .build-id section generated by gcc is discarded.
git-blame is your friend. It leads to commit 7fd5d619806d ("BaseTools
GCC: drop GNU notes section from EFI image", 2016-08-02).
The build-id is used by Linux distros when they ship debug symbols with production shared libraries. The build-id permits the loader to look up the correct file, and confirm that the versions match.

In EDK2, the ELF binary is only an intermediate artifact, and so I fail to see why we would need build IDs here. If the ELF binary was built with debug symbols, they will be in the binary itself, not in a side loaded symbol file.

Join to automatically receive all group messages.