From patchwork Wed Mar 30 10:50:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 64678 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp2516865lbc; Wed, 30 Mar 2016 03:50:34 -0700 (PDT) X-Received: by 10.66.248.198 with SMTP id yo6mr11856950pac.54.1459335034118; Wed, 30 Mar 2016 03:50:34 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [2001:19d0:306:5::1]) by mx.google.com with ESMTPS id vx8si5726963pac.107.2016.03.30.03.50.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Mar 2016 03:50:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 2001:19d0:306:5::1 as permitted sender) client-ip=2001:19d0:306:5::1; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 2001:19d0:306:5::1 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 389F11A1F9A; Wed, 30 Mar 2016 03:51:03 -0700 (PDT) X-Original-To: edk2-devel@ml01.01.org Delivered-To: edk2-devel@ml01.01.org Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2F9F61A1F99 for ; Wed, 30 Mar 2016 03:51:01 -0700 (PDT) Received: by mail-ig0-x22d.google.com with SMTP id l20so37850402igf.0 for ; Wed, 30 Mar 2016 03:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=uv19VGtNlU6uzgkfoH97Vad41zB61dYqEZvKi9rhDFg=; b=YP+mqxxWXDWMqogxXuCK5FdLQysIVXNc4eyzjm9ALOqsufhO+8M42c/AejDbDBsHuF AtLgDAAD2CiwPv9m/9BkTLPIe3XRFsz2hmHffab6GiXaYoR/lqHIIzWIKsx4xQHlcS/M stxdIt7joUvnFw/0avoO7lbVZ29xRpfnsfoPg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=uv19VGtNlU6uzgkfoH97Vad41zB61dYqEZvKi9rhDFg=; b=kl2kR2JrWjyKMRF+H7klq6hV2hZuLi/t2/yP8LBJRverM2SC4kqLmXlMCQmZCYv6Hu xZoS0+HdGeqQQgXMB79fK6oO+5F9O+qol5I31CFLhiEAB4pqT8hCKPVUM3wp1+d59Ow1 RbHocQhKNmDSdU+sDlJ5fQuRpp7xQ1AkkKbQe1Tz3CMPQvY/Zm6lzAGJ1KPIlp5ahvTP QqwXGYgRbv/+qiGxCoFrku37HIbd8HO7FHYOyosfOZvElieeI+3uuAwLPZPV1vrbiEQ6 kxSzQC2SKlfNFq/zHk9VfVgF5/3A4CFgUVtTRe1S2QIBgVNxAJ00flERpx85/R1xnn9+ shZA== X-Gm-Message-State: AD7BkJKIdKjjJop7RWN+Fuker4+1kuTyxGQ3PuQ6jOmru+r4k9ct7DDGhjdDTlTHJ9ULHkRBqnMY77d/PVCK1GBp MIME-Version: 1.0 X-Received: by 10.50.50.234 with SMTP id f10mr22138823igo.37.1459335030706; Wed, 30 Mar 2016 03:50:30 -0700 (PDT) Received: by 10.36.29.6 with HTTP; Wed, 30 Mar 2016 03:50:30 -0700 (PDT) In-Reply-To: References: <2211829a1337969c86e13f23e05eb7e9@mail.gmail.com> <20E18501-ACD0-4B6E-ABBA-CDB69D59CB47@apple.com> <451e7e28c704903db2915ffc38d0eac2@mail.gmail.com> Date: Wed, 30 Mar 2016 12:50:30 +0200 Message-ID: From: Ard Biesheuvel To: Vladimir Olovyannikov Subject: Re: [edk2] Error while loading a symbol file (No Debug Directory) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "edk2-devel@lists.01.org" , "afish@apple.com" , Eugene Cohen Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" On 30 March 2016 at 12:30, Ard Biesheuvel wrote: > On 30 March 2016 at 02:06, Vladimir Olovyannikov > 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 >>> 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 --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)