On Nov 28, 2012, at 11:18 AM, Shivamurthy Shastri wrote:
> Hi Andrew,
>
> I am using Trace32 for debugging.
Not sure if there a scripts around for this, maybe the ARM Ltd. guys would
know? The ARM JTAG debugger scripts seem to live @
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ArmPlatformPkg/Scripts/Ds5/
I just noticed this in the BeagleBoardPkg:
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BeagleBoardPkg/Debugger_scripts/trace32_load_symbols.cmm
So the load_symbols: command is not what you want as it does the DXE lookup the
table and find all the symbols thing. You want to use the basic
load_symbol_file:.
> I need COFF file for debugging. Is there any single final COFF file for
> debugging?
>
Not sure what you mean by that. I think the answer is NO. The *.EFI file is the
PE/COFF image and it is linked at 0x000 or ~0x240 (converted from ELF/Mach-O).
So it is the correct image, but not relocated to its executable address. The
tool that constructs the FV/FD does this final relocation. So what you have to
do in the debugger is tell the debugger where the symbols are loaded. Something
like:
load_symbol_file
Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/DEBUG/SecMain.dll
0xEF0001240
The file name you give is NOT the PE/COFF .efi file. It needs to be the file
that contains the symbolic debug information. So it could the the original ELF.
For a Microsoft toolchain this is the *.pdb file.
If I do a quick look I see a file in the build results directory that may be
helpful for you (here is my example):
Build/Emulator/DEBUG_XCLANG/EmulatorPkg.map
EmuSec (Fixed Flash Address, BaseAddress=0x01020001a0, EntryPoint=0x0102003a90)
(GUID=BCAF98C9-22B0-3B4F-9CBD-C8A6B4DBCEE9 .textbaseaddress=0x01020003e0
.databaseaddress=0x0102004fc0)
(IMAGE=/Users/fish/work/edk2TOT/Build/Emulator/DEBUG_XCLANG/X64/EmulatorPkg/Sec/Sec/DEBUG/EmuSec.efi)
PeiCore (Fixed Flash Address, BaseAddress=0x01020052a0, EntryPoint=0x0102008af0)
(GUID=52C05B14-0B98-496C-BC3B-04B50211D680 .textbaseaddress=0x01020054e0
.databaseaddress=0x0102019740)
(IMAGE=/Users/fish/work/edk2TOT/Build/Emulator/DEBUG_XCLANG/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.efi)
....
It should be possible to post process this file and build a file you can import
into Trace32 to load symbols for all the execute from FD/FV code.
BaseAddress == your load addresss and IMAGE == the PE/COFF file (remember it
points to the file that contains the symbols).
In this example since I built with clang and produced a Mach-O my load command
would look like:
load_symbol_file
/Users/fish/work/edk2TOT/Build/Emulator/DEBUG_XCLANG/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll
0x01020003e0
I know that my PE/COFF points to the Mach-O for the symbols and the Mach-O has
a .dll extension. Also you can see by the textbaseaddress that this image is
linked at 0x240 and not zero, and the Mach-O (ELF) file has no concept of the
first 0x240 bytes that contain the PE/COFF header this is why you have to add
0x240 to the load address.
Good Luck!
Andrew
PS If your debugger is PE/COFF aware it may be possible to pass the PE/COFF
*.efi file directly. But the debugger is going the crack open the PE/COFF file
and find the debug directory entry that points to the symbol file and load it
for you.
>
> On Wed, Nov 28, 2012 at 9:09 PM, Andrew Fish <[email protected]> wrote:
> James,
>
> This could have to do with you looking at the object file that has NOT been
> linked, the things that are zero probably need to get resolved by the linker.
>
> You want to look at the linked output and that should be in the
> Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/DEBUG
> directory. Try the *.efi, this should work if you objdump supports PE/COFF.
> If this does not work then look at the *.dll file. You should also be able
> to look at the map file, *.map, to get info about the link.
>
> Andrew Fish
>
>
> On Nov 28, 2012, at 2:45 AM, James White wrote:
>
>> Thanks for your help.
>>
>> When I look at just the first few lines of the disassembled code of
>> SecEntryPoint.S then I get the following output:
>>
>> arm-linux-gnueabi-objdump -d
>> Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/OUTPUT/SecEntryPoint.obj
>>
>>
>> Build/ArmVExpress-RTSM-A15_MPCore/DEBUG_ARMLINUXGCC/ARM/ArmPlatformPkg/Sec/Sec/OUTPUT/SecEntryPoint.obj:
>> file format elf32-littlearm
>>
>> Disassembly of section .text:
>>
>> 00000000 <StartupAddr>:
>> 0: 00000000 .word 0x00000000
>>
>> 00000004 <_ModuleEntryPoint>:
>> 4: ebfffffe bl 0 <ArmDisableInterrupts>
>> 8: ebfffffe bl 0 <ArmDisableCachesAndMmu>
>> c: e3a0a001 mov sl, #1
>> 10: fafffffe blx 0 <ArmPlatformSecBootAction>
>>
>> 00000014 <_IdentifyCpu>:
>> 14: ebfffffe bl 0 <ArmReadMpidr>
>> 18: e59f10a4 ldr r1, [pc, #164] ; c4 <_NeverReturn+0x4>
>> 1c: e0005001 and r5, r0, r1
>> 20: e3a03000 mov r3, #0
>> 24: e1550003 cmp r5, r3
>> 28: 0a000003 beq 3c <_InitMem>
>>
>> I am a bit surprised that it seem that all functions outside of Sec are set
>> to "0", e.g. ArmDisableInterrupts etc. Or do I not read it properly? When
>> are the addresses of those functions defined? Does that part come later when
>> linking all of them together as single binary?
>>
>
> Yes
>
>> Thanks for any pointers.
>>
>> From: [email protected]
>> Date: Tue, 27 Nov 2012 11:25:22 -0800
>> To: [email protected]
>> Subject: Re: [edk2] Disassemble UEFI FV
>>
>>
>> On Nov 27, 2012, at 9:21 AM, James White wrote:
>>
>> Hi Andrew
>>
>> Thanks for your reply. Great help.
>>
>> I currently have the problem that I'm trying to split SEC from PEI/DXE/BDS.
>> I load the Sec module into a read-only ROM. The ROM is memory-mapped at 0x0
>> (this is specific to my platform).
>> When I disassemble Sec/Sec/OUTPUT/SecEntryPoint.obj I can see that the
>> address of CEntryPoint/StartupAddr is 0x0.
>>
>> 00000000 <StartupAddr>:
>> 0: 00000000 .word 0x00000000
>>
>> This is the entry point for Sec.c (not the startup function of
>> SecEntryPoint.S) but doesn't that conflict with me having the ROM mapped at
>> 0x0?
>> I cannot get any output of my system because it fails so early at power on.
>> I'm currently using ARM's Fast Model simulation to find the problem.
>>
>>
>> You can look at the link map for Sec and see the linked address of the
>> symbols. It is likely that the Sec will be linked at 0x00000000 or
>> 0x00000240 (started with non-PE/COFF image). The info in the FDF file is
>> used to relocate Sec to its execute in place address. So In my example that
>> would shift everything over by 0xEC000000 + offset of the Sec PE/COFF image
>> in the FD.
>>
>> Just to clarify, what exactly does the BaseAddress mean? Is that where the
>> flash device is memory-mapped on the system, or just some location in RAM
>> where we can relocate code to?
>>
>>
>> This is the address the FD will execute from. So on a PC this a FLASH ROM
>> address. On a BeagleBoard the mask ROM turns on DRAM and reads a table from
>> ROM and shadows the FD into RAM, so it is a RAM address.
>>
>> Thanks again for your help.
>>
>>
>> From: [email protected]
>> Date: Tue, 27 Nov 2012 08:44:13 -0800
>> To: [email protected]
>> Subject: Re: [edk2] Disassemble UEFI FV
>>
>> The edk2 build system produces a command line tool called VolInfo that dumps
>> FVs. It does not disassemble code, but it will show you the layout.
>>
>> The FD layout is defined in the platforms .FDF file. Look in the [FD.*]
>> sections. So for example:
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ArmPlatformPkg/ArmPlatformPkg.fdf
>> [FD.Sec_ArmPlatform_EFI]
>> BaseAddress = 0xEC000000|gArmTokenSpaceGuid.PcdSecureFdBaseAddress #The
>> base address of the Secure FLASH Device.
>> Size = 0x00010000|gArmTokenSpaceGuid.PcdSecureFdSize #The
>> size in bytes of the Secure FLASH Device
>> ErasePolarity = 1
>> BlockSize = 0x00001000
>> NumBlocks = 0x10
>> 0x00000000|0x00010000
>> gArmTokenSpaceGuid.PcdSecureFvBaseAddress|gArmTokenSpaceGuid.PcdSecureFvSize
>> FV = FVMAIN_SEC
>> So FVMAIN_SEC is relocated to 0xEC000000. This relocation is done when the
>> build calls GenFv. The FV header starts with a zero vector (16-bytes of
>> zero), on ARM these values are patched with a branch to the entry point of
>> the SEC Core. See UpdateArmResetVectorIfNeeded() in
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BaseTools/Source/C/GenFv/GenFvInternalLib.c.
>>
>>
>> The FV layout is completely defined in the UEFI Platform Initialization (PI)
>> Specification 1.2.1 @ http://www.uefi.org/specs/
>>
>> Disassembly is usually done via a JTAG debugger (I assume you don't have
>> one) or by using a debugger. So if you have gdb you can use the VolInfo +
>> info in the .FDF file to calculate the offset of the Sec PE/COFF image. You
>> can then load the binary into the debugger and disassemble. There are two
>> things to look out for:
>> 1) A Section in a FV File contains a section header, so make sure you are
>> using the start of the PE/COFF image, and not the section header in front of
>> the PE/COFF image
>> 2) In general all images in edk2 are linked a zero. If the build tools
>> produce an ELF or Mach-O file and convert it to PE/COFF then the image is
>> linked at the size of the PE/COFF header. This is due to the PE/COFF header
>> getting loaded into memory when the image is loaded, but the ELF or Mach-O
>> headers do not get copied into memory. So for example you often have to add
>> 0x240 to the load address to get symbols to work correctly. Think load
>> address + link address.
>>
>> Given the start of the FV will be a branch to the SEC PE/COFF image entry
>> point you should be able verify you are doing the math correctly.
>>
>> It may be possible to write a debugger script that loads the FD into memory,
>> and then you can disassemble it with the given offsets. In gdb you may be
>> able to use `restore Sec_ArmPlatform_EFI.fd 0xEC000000 0xEC00FFFF`. Don't
>> forget to set the processor architecture in the debugger, and you may have
>> to use 0 vs. the real address depending on what is legal virtual address
>> space for an application on your build platform.
>>
>> For the ARM debugger there seems to be scripts to crack FVs:
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>> On Nov 27, 2012, at 7:10 AM, James White wrote:
>>
>> Is there a way that I can disasseble my generated UEFI binary (in my case
>> FV/SEC_RTSM_VE_CORTEX-A15_MPCORE_EFI.fd) so that I can see the exact
>> instructions that are being run once the firmware is executed from ROM?
>> Is there documentation about the format of that .fd? In my case I only have
>> the Sec module in the binary but I can see that the .fd is not exactly the
>> same as Sec/Sec/OUTPUT/ArmPlatformSec.efi - what is the difference?
>> Can anyone recommend a good disassembler for ARM EFI binaries?
>>
>> Thanks for any pointers.
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
>> edk2-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single web
>> console. Get in-depth insight into apps, servers, databases, vmware, SAP,
>> cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from
>> $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________ edk2-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
>> edk2-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your
>> parallel project right.http://goparallel.sourceforge.net
>>
>> _______________________________________________ edk2-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net_______________________________________________
>> edk2-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> --
> Thanks and Regards,
> Shiva.
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net_______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
