diff mbox

[edk2] Error while loading a symbol file (No Debug Directory)

Message ID CAKv+Gu-OXPCuwNteeCv0iXVnNtN5yf_1PjpTQoX1bfDz5kBnSw@mail.gmail.com
State New
Headers show

Commit Message

Ard Biesheuvel March 30, 2016, 10:50 a.m. UTC 
On 30 March 2016 at 12:30, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 30 March 2016 at 02:06, Vladimir Olovyannikov

> <vladimir.olovyannikov@broadcom.com> wrote:

>>> -----Original Message-----

>>> From: afish@apple.com [mailto:afish@apple.com]

>>> Sent: Tuesday, March 29, 2016 4:09 PM

>>> To: Vladimir Olovyannikov

>>> Cc: Eugene Cohen; Ard Biesheuvel; edk2-devel@lists.01.org

>>> Subject: Re: [edk2] Error while loading a symbol file (No Debug

>> Directory)

>>>

>>>

>>> > On Mar 29, 2016, at 3:18 PM, Vladimir Olovyannikov

>>> <vladimir.olovyannikov@broadcom.com> wrote:

>>> >

>>> > A quick update on the issue (I am using the latest master branch

>> tree).

>>> >

>>> > Eugene is right in that excluding ImageContext->SizeOfHeaders gives

>>> > correct address, and using

>>> > "add-symbol-file...." I can do source level debugging in the DS-5

>>> > debugger.

>>> > So it was sufficient to change

>>> > ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c

>>> > (around line 94)

>>> > DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",

>>> >     DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof

>>> > (Temp)),

>>> >     (UINTN)(ImageContext->ImageAddress +

>>> > ImageContext->SizeOfHeaders)));

>>> > to

>>> > DEBUG ((EFI_D_LOAD | EFI_D_INFO, "add-symbol-file %a 0x%p\n",

>>> >     DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof

>>> > (Temp)),

>>> >      (UINTN)(ImageContext->ImageAddress)));

>>> >

>>> > as well as around line 131 (which is optional) ("remove-symbol-file").

>>> > It is probably a dirty hack but works fine for me.

>>>

>>> Vladimir,

>>>

>>> I'm not sure what is happening in your case but in general we run into

>> issues

>>> when converting other executable formats (ELF, Mach-O) into PE/COFF as

>>> PE/COFF has the concept of the COFF header being loaded into system

>>> memory and other formats do not. So adding in ImageContext-

>>> >SizeOfHeaders is adjusting for the difference between how the ELF was

>>> constructed prior to conversion to PE/COFF. In some cases the ELF is

>> linked

>>> with an adjustment for the PE/COFF header and in this case you tend to

>> use

>>> the start of the image. If the ELF image was just linked at zero then

>> you need

>>> to adjust for the size of the PE/COFF header.

>>>

>>> It looks like the GCC linker script BaseTools/Scripts/GccBase.lds does

>> some

>>> link time adjustment to leave size for the PE/COFF header. Thus these

>>> toolchains would probably need to use ImageContext->ImageAddress vs.

>>> ImageContext->ImageAddress + ImageContext->SizeOfHeaders. It also looks

>>> like the RVCT has a linker script that reservers 0x220 bytes for a

>> PE/COFF

>>> header.

>>>

>>> The, slightly mangled, comment right before the GCC add-symbol-file

>> DEBUG

>>> print is pointing out the + ImageContext->SizeOfHeaders could be

>> optional. I

>>> would think if you are linking the ELF to include space for the PE/COFF

>> header

>>> then you should fall into the no + ImageContext->SizeOfHeaders is

>> required.

>>>

>>>     // This may not work correctly if you generate PE/COFF directlyas

>> then the

>>> Offset would not be required

>>>

>>> So I wonder if these DEBUG prints are out of sync with the current

>> linker

>>> flags? If I thought  the add-symbol-file address was always the start of

>> the

>>> image. Adding in the PE/COFF SizeOfHeaders would only bee needed if the

>>> ELF was constructed without adjustment for the PE/COFF header. Looks

>> like

>>> most of the targets do this adjustment?

>>>

>

> I am not familiar with DS-5, but the current output of

> 'add-symbol-file' is correct for GDB, since that expects the address

> of the .text section as a second parameter.

>

> Formerly, the start of the .text section would coincide with the start

> of the image, since ELF headers are typically covered by a section. In

> PE/COFF, this is not the case, and due to some changes that were

> needed to support relative relocations, the .text section no longer

> resides at the start of the ELF image.

>

> So my suspicion is that whatever is consuming the 'add-symbol-file'

> lines in your case deviates from GDB by expecting the image start

> address rather than the .text section start address, and this is where

> stuff starts to break.

>

>> Thanks for the input Andrew,

>> For me it all started only after applying of commit

>> 2939c778a3a3f5463d97339f4f3dbf5afb572a5e,

>> ArmPkg: ARM/AArch64 implementation of CpuExceptionHandlerLib,

>> though I do not see how this commit could affect (SizeOfHeaders + Base)

>> address...

>>

>

> It may affect the aligment of the ELF .text section

>

>> As soon as I checkout the previous

>> (d2bb61a2328d512c0aeb201ab8a5a6497f415afb,

>> ArmPkg/ArmLib: add ArmReadHcr to enable read-modify-write of HCR),

>> everything is fine.

>>

>

> That is *very* strange, since the first commit simply adds code that

> is not even used if you don't refer to it in your .DSC

>

>> The commit f37d891c1b870b294964adf65f619a661700fcab,

>> BaseTools AARCH64: move DEBUG GCC49 to the small code model,

>> causes this when I run cmd_load_symbols.py script in DS-5 debugger:

>> Add symbols of

>> /uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBU

>> G/ArmPlatformPrePiMPCore.dll at 0x85000000

>> Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)

>> ...Same line 30 times...

>> Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)

>> Add symbols of

>> /work/jenkins/workspace/ap-uefi-bin/EDK2_ARCH/ARM/EDK2_BINARY/FatPkg/label

>> /sas-sw/Build/Fat/RELEASE_GCC49/AARCH64/FatPkg/EnhancedFatDxe/Fat/DEBUG/Fa

>> t.dll at 0xb9f85000

>> Warning: not possible to load symbols from

>> /work/jenkins/workspace/ap-uefi-bin/EDK2_ARCH/ARM/EDK2_BINARY/FatPkg/label

>> /sas-sw/Build/Fat/RELEASE_GCC49/AARCH64/FatPkg/EnhancedFatDxe/Fat/DEBUG/Fa

>> t.dll at 0xb9f85000

>> Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)

>> ...Same line 12 times....

>> Error while loading a symbol file (EfiFileSectionPE64: No Debug Directory)

>>

>> This does not affect add-symbol-file debugging, whereas

>> cmd_load_symbols.py script was useless since

>> 2939c778a3a3f5463d97339f4f3dbf5afb572a5e commit.

>> I think there is a line which adds SizeOfHeaders (or similar) to the base

>> address in a DS-5 python script,

>> but I am not familiar with the design, and as soon as "add-symbol-file"

>> works for me, I am OK.

>>

>> I am wondering if I am the only one who is affected with this DS-5 script

>> behavior?

>>


Could you try this patch, please?

+        debug_dir_entry_rva =
self.ec.getMemoryService().readMemory32(self.base_pe64 +
file_header_offset + 0xB8)
         if debug_dir_entry_rva == 0:
             raise Exception("EfiFileSectionPE64","No Debug Directory")
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
diff mbox

Patch

diff --git a/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
b/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
index c434e3de19da..9a76ae066d9a 100644
--- a/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
+++ b/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
@@ -138,11 +138,10 @@  class EfiSectionPE64:

     def get_debug_filepath(self):
         # Offset from dos hdr to PE file hdr (EFI_IMAGE_NT_HEADERS64)
-        #file_header_offset =
self.ec.getMemoryService().readMemory32(self.base_pe64 + 0x3C)
-        file_header_offset = 0x0
+        file_header_offset =
self.ec.getMemoryService().readMemory32(self.base_pe64 + 0x3C)

         # Offset to debug dir in PE hdrs
-        debug_dir_entry_rva =
self.ec.getMemoryService().readMemory32(self.base_pe64 +
file_header_offset + 0x138)