efi/arm64: add vmlinux link to PE/COFF debug table

When building with debugging symbols, take the absolute path to the vmlinux binary and add it to the special PE/COFF debug table entry.

These entries are used internally by EDK2 based* debug builds of UEFI to populate the DebugImageInfo table, which can be used by debuggers as well as by the OS itself to retrieve information about all loaded PE/COFF executables. This is highly useful for source level debugging of the UEFI stub.

* for AArch64, this probably means all of them

Cc Matt Fleming <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm64/kernel/Makefile |  4 +++
 arch/arm64/kernel/head.S   | 34 +++++++++++++++++++-
 arch/arm64/kernel/image.h  |  3 ++
 3 files changed, 40 insertions(+), 1 deletion(-)

arch/arm64/kernel/Makefile +4 -0

index 7d66bbaafc0c..6dbc0e5527f5 100644
@@ -55,3 +55,7 @@ obj-y                                 += $(arm64-obj-y) vdso/ probes/
 obj-m                                  += $(arm64-obj-m)
 head-y                                 := head.o
 extra-y                                        += $(head-y) vmlinux.lds
+
+ifeq ($(CONFIG_EFI)$(CONFIG_DEBUG_INFO),yy)
+AFLAGS_head.o += -DVMLINUX_PATH="\"$(shell readlink -f $(objtree)/vmlinux)\""
+endif

arch/arm64/kernel/head.S +33 -1

index 4b1abac3485a..b462ab1f11ef 100644
@@ -149,7 +149,7 @@ extra_header_fields:
        .quad   0                               // SizeOfHeapReserve
        .quad   0                               // SizeOfHeapCommit
        .long   0                               // LoaderFlags
-       .long   0x6                             // NumberOfRvaAndSizes
+       .long   (section_table - .) / 8         // NumberOfRvaAndSizes
 
        .quad   0                               // ExportTable
        .quad   0                               // ImportTable

@@ -158,6 +158,11 @@ extra_header_fields:
        .quad   0                               // CertificationTable
        .quad   0                               // BaseRelocationTable
 
+#ifdef CONFIG_DEBUG_INFO
+       .long   efi_debug_table - _head         // DebugTable
+       .long   efi_debug_table_size
+#endif
+
        // Section table
 section_table:
 

@@ -204,6 +209,33 @@ section_table:
         */
        .align 12
 efi_header_end:
+
+#ifdef CONFIG_DEBUG_INFO
+       __INITDATA
+
+efi_debug_table:
+       // EFI_IMAGE_DEBUG_DIRECTORY_ENTRY
+       .long   0                       // Characteristics
+       .long   0                       // TimeDateStamp
+       .short  0                       // MajorVersion
+       .short  0                       // MinorVersion
+       .long   2                       // Type == EFI_IMAGE_DEBUG_TYPE_CODEVIEW
+       .long   efi_debug_entry_size    // SizeOfData
+       .long   efi_debug_entry_offset  // RVA
+       .long   efi_debug_entry_offset  // FileOffset
+
+ENTRY(efi_debug_entry)
+       // EFI_IMAGE_DEBUG_CODEVIEW_NB10_ENTRY
+       .long   0x3031424E              // Signature
+       .long   0                       // Unknown
+       .long   0                       // Unknown2
+       .long   0                       // Unknown3
+
+       .asciz  VMLINUX_PATH
+
+       .set    efi_debug_entry_size, . - efi_debug_entry
+       .set    efi_debug_table_size, . - efi_debug_table
+#endif
 #endif
 
        __INIT

arch/arm64/kernel/image.h +3 -1

index c7fcb232fe47..ad5406f011c2 100644
@@ -116,6 +116,9 @@ __efistub__end                      = KALLSYMS_HIDE(_end);
 __efistub__edata               = KALLSYMS_HIDE(_edata);
 __efistub_screen_info          = KALLSYMS_HIDE(screen_info);
 
+#ifdef CONFIG_DEBUG_INFO
+efi_debug_entry_offset = efi_debug_entry - _text;
+#endif
 #endif
 
 #endif /* __ASM_IMAGE_H */
--

2.7.4

When building with debugging symbols, take the absolute path to the vmlinux binary and add it to the special PE/COFF debug table entry.

These entries are used internally by EDK2 based* debug builds of UEFI to populate the DebugImageInfo table, which can be used by debuggers as well as by the OS itself to retrieve information about all loaded PE/COFF executables. This is highly useful for source level debugging of the UEFI stub.

* for AArch64, this probably means all of them

Cc Matt Fleming <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm64/kernel/Makefile |  4 +++
 arch/arm64/kernel/head.S   | 34 +++++++++++++++++++-
 arch/arm64/kernel/image.h  |  3 ++
 3 files changed, 40 insertions(+), 1 deletion(-)

arch/arm64/kernel/head.S +1 -0

+efi_debug_table:

Quoted 8 lines · Ard Biesheuvel

When building with debugging symbols, take the absolute path to the vmlinux binary and add it to the special PE/COFF debug table entry.

These entries are used internally by EDK2 based* debug builds of UEFI to populate the DebugImageInfo table, which can be used by debuggers as well as by the OS itself to retrieve information about all loaded PE/COFF executables. This is highly useful for source level debugging of the UEFI stub.

Does that mean EFI_IMAGE_DEBUG_DIRECTORY_ENTRY and friends are EDK2-specific?

Or just that the way EDK2 happens to use those is EDK2-specific?

Quoted 11 lines

* for AArch64, this probably means all of them

Cc Matt Fleming <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm64/kernel/Makefile |  4 +++
 arch/arm64/kernel/head.S   | 34 +++++++++++++++++++-
 arch/arm64/kernel/image.h  |  3 ++
 3 files changed, 40 insertions(+), 1 deletion(-)

arch/arm64/kernel/head.S +1 -0

+efi_debug_table:

arch/arm64/kernel/head.S section_table:

Quoted 10 lines

arch/arm64/kernel/head.S +9 -0

+     // EFI_IMAGE_DEBUG_DIRECTORY_ENTRY
+     .long   0                       // Characteristics
+     .long   0                       // TimeDateStamp
+     .short  0                       // MajorVersion
+     .short  0                       // MinorVersion
+     .long   2                       // Type == EFI_IMAGE_DEBUG_TYPE_CODEVIEW
 
+ENTRY(efi_debug_entry)
+     // EFI_IMAGE_DEBUG_CODEVIEW_NB10_ENTRY
+     .long   0x3031424E              // Signature

Certainly not a blocker for this, but this reminds me that it would be nice to de-magic the EFI constants used by the stub.

I took a stab a while back [1], for the existing definitions, but that fell by the wayside.

Quoted 13 lines · Mark Rutland

Quoted 8 lines · Ard Biesheuvel

When building with debugging symbols, take the absolute path to the vmlinux binary and add it to the special PE/COFF debug table entry.

These entries are used internally by EDK2 based* debug builds of UEFI to populate the DebugImageInfo table, which can be used by debuggers as well as by the OS itself to retrieve information about all loaded PE/COFF executables. This is highly useful for source level debugging of the UEFI stub.

Does that mean EFI_IMAGE_DEBUG_DIRECTORY_ENTRY and friends are EDK2-specific?

Quoted 1 line

Or just that the way EDK2 happens to use those is EDK2-specific?

Those values are defined by the PE/COFF spec, and I assume that a CodeView type entry in the debug table usually contains a NUL terminated string as well, given that the EDK2 crowd is very Wintel-heavy.

The significance of mentioning EDK2 here was that I thought that the DebugImageInfo table was a PI construct rather than something described in the UEFI spec. But looking more carefully, it seems that this table is in fact a UEFI construct, so I should probably drop this mention from the commit log

Quoted 14 lines · Ard Biesheuvel

Quoted 13 lines · Mark Rutland

Quoted 8 lines · Ard Biesheuvel

When building with debugging symbols, take the absolute path to the vmlinux binary and add it to the special PE/COFF debug table entry.

These entries are used internally by EDK2 based* debug builds of UEFI to populate the DebugImageInfo table, which can be used by debuggers as well as by the OS itself to retrieve information about all loaded PE/COFF executables. This is highly useful for source level debugging of the UEFI stub.

Does that mean EFI_IMAGE_DEBUG_DIRECTORY_ENTRY and friends are EDK2-specific?

Quoted 6 lines

Quoted 1 line

Or just that the way EDK2 happens to use those is EDK2-specific?

Those values are defined by the PE/COFF spec, and I assume that a CodeView type entry in the debug table usually contains a NUL terminated string as well, given that the EDK2 crowd is very Wintel-heavy.

So we don't actually have a definition of the format of a CodeView entry, and we're guessing?

That does feel a little scary, especially given the fields are named "Unknown". :(

Quoted 5 lines

The significance of mentioning EDK2 here was that I thought that the DebugImageInfo table was a PI construct rather than something described in the UEFI spec. But looking more carefully, it seems that this table is in fact a UEFI construct, so I should probably drop this mention from the commit log

That would probably be for the best, yes.

Quoted 22 lines · Mark Rutland

Quoted 20 lines · Ard Biesheuvel

Quoted 10 lines · Mark Rutland

Quoted 8 lines · Ard Biesheuvel

When building with debugging symbols, take the absolute path to the vmlinux binary and add it to the special PE/COFF debug table entry.

These entries are used internally by EDK2 based* debug builds of UEFI to populate the DebugImageInfo table, which can be used by debuggers as well as by the OS itself to retrieve information about all loaded PE/COFF executables. This is highly useful for source level debugging of the UEFI stub.

Quoted 4 lines

Does that mean EFI_IMAGE_DEBUG_DIRECTORY_ENTRY and friends are EDK2-specific?

Or just that the way EDK2 happens to use those is EDK2-specific?

Those values are defined by the PE/COFF spec, and I assume that a CodeView type entry in the debug table usually contains a NUL terminated string as well, given that the EDK2 crowd is very Wintel-heavy.

Quoted 5 lines

So we don't actually have a definition of the format of a CodeView entry, and we're guessing?

That does feel a little scary, especially given the fields are named "Unknown". :(

No, we are emitting them in exactly the same way as the EDK2 tooling emits them,