[PATCH v2 2/2] arm64: efi: add vmlinux debug link to the Image binary

[Ard Biesheuvel]

On 26 January 2017 at 18:26, Mark Rutland <mark.rutland at arm.com> wrote:
> On Wed, Jan 25, 2017 at 12:00:44PM +0000, Ard Biesheuvel wrote:
>> On 25 January 2017 at 11:53, Mark Rutland <mark.rutland at arm.com> wrote:
>> > On Wed, Jan 25, 2017 at 10:39:19AM +0000, Ard Biesheuvel wrote:
>> >> 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?
>>
>> 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". :(
>

No, we are emitting them in exactly the same way as the EDK2 tooling
emits them, which is not entirely unreasonable given that
a) the EDK2 tooling was created by Intel engineers in an attempt to
generate Visual Studio compatible PE/COFF images, and
b) someone hacking on the arm64 Linux kernel on a UEFI system is
likely to be using EDK2 based firmware, and *highly* unlikely to be
using Visual Studio.

>> 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.
>

Yes I will update the commit log for v3