> On Nov 23, 2015, at 11:31 PM, Ard Biesheuvel <ard.biesheu...@linaro.org> > wrote: > > On 24 November 2015 at 00:38, Vladimir Olovyannikov > <volov...@broadcom.com> wrote: >> >> >>> -----Original Message----- >>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >>> Sent: Tuesday, November 10, 2015 10:04 AM >>> To: Vladimir Olovyannikov >>> Cc: Cohen, Eugene; edk2-devel@lists.01.org >>> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with >>> step-by-step debugging in uefi >>> >>> On 10 November 2015 at 18:41, Vladimir Olovyannikov >>> <volov...@broadcom.com> wrote: >>>> Ard, >>>> Many thanks for your help. It works. >>>> >>> >>> Great! Thanks for reporting back. >>> >>> >>>> -----Original Message----- >>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >>>> Sent: Monday, November 09, 2015 10:31 PM >>>> To: Vladimir Olovyannikov >>>> Cc: Cohen, Eugene; edk2-devel@lists.01.org >>>> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 >>> with step-by-step debugging in uefi >>>> >>>> On 9 November 2015 at 19:01, Vladimir Olovyannikov >>>> <volov...@broadcom.com> wrote: >>>>> -----Original Message----- >>>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >>>>> Sent: Sunday, November 08, 2015 10:52 PM >>>>> To: Vladimir Olovyannikov >>>>> Cc: Cohen, Eugene; edk2-devel@lists.01.org >>>>> Subject: Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 >>> with step-by-step debugging in uefi >>>>> >>>>> On 6 November 2015 at 21:32, Vladimir Olovyannikov >>>>> <volov...@broadcom.com>> wrote: >>>>>>> Hello Ard, Eugene, >>>>>>> Thank you for explanation. >>>>>>> >>>>>>> Ard, I tried the patch, but it cannot be applied to the latest (pulled a >>> minute ago, git-svn-id: >>> https://svn.code.sf.net/p/edk2/code/trunk/edk2@18732 6f19259b-4bc3- >>> 4df7-8a09-765794883524) >>>>>>> tree: all 3 hunks failed. Which commit should I be based on to apply the >>> patch? >>>>>>> >>>>>>> Anyway I found the lines manually and changed them. However, when >>> I try to >>>>>>> >>>>>>> source /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f >>> (0x85000000,0x00280000) -m (0x80000000,0x40000000) -a >>>>>>> I am getting >>>>>>> >>>>>>> ERROR(?): ValueError: need more than 1 value to unpack >>>>>>> File " /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py", line >>> 94, in <module>> >>>>>>> armplatform_debugger.load_all_symbols() >>>>>>> ERROR(CMD656): >>>>>>> # in /uefi/BroadcomPlatformPkg/NS2Pkg/Scripts/armpkg_syms.ds:2 >>> while executing: source >>> /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f >>> (0x85000000,0x00280000) -m (0x80000000,0x40000000) -a >>>>>>> ! The script /uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py >>> failed to complete due to an error during execution of the script >>>>>>> >> [...] >> Ard, I got a pretty much the same issue when I tried to do some debugging in >> the ShellPkg. >> Except Shell I can perfectly debug everything. >> >> 1. source / uefi/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py -f >> (0x85000000,0x00280000) -m (0x80000000,0x40000000) -a >> loads symbols fine, but does not recognize any module matching the >> current PC if stopped in the shell. >> 2. Loading symbols with "add-symbol-file >> /uefi/Build/NS2Pkg/DEBUG_GCC49/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll >> 0xB6926000" >> "recognizes" modules (wrong ones though) but the source code does not >> match disassembly. >> >> So with Shell debug using DS-5 the code does not match the source. >> Is there a special linker setting I am missing or a technique? >> I am using the latest UEFI code from >> https://github.com/tianocore/edk2.git >> > > I am sorry, but since I don't have access to DS-5, I am not sure how > to debug this. > > Is there any way for you to figure how much the offset is between the > current and the correct location? I.e., by looking at the ELF asm dump > and the instructions around the PC? Something in the order of 0x260 > perhaps? >
The map file in the build output directory is useful for tracking down these kind of issues. Issues like this usually relate to the fact that PE/COFF images load the PE/COFF header into memory when the code is loaded, while ELF (and Mach-O) do not do this. This means you have to shift the link address from 0 to the size of the PE/COFF header (0x260 is one possible size of the PE/COFF header). Basically it is part of the ELF to PE/COFF conversion magic. Maybe the ELF to PE/COFF conversion tool and the debugger script our out of sync? The other thing to look out for is TE (Tiano Executable) images. They have a stripped down version of a PE/COFF header to save space, and they are mostly used for PEI modules that run from FLASH. You have to add a negative adjustment to get the symbols loaded correctly. Thanks, Andrew Fish > -- > Ard. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
