On Jul 29, 2014, at 5:32 AM, Varad Gautam <varadgau...@gmail.com> wrote:
> On Tue, Jul 29, 2014 at 3:34 PM, Olivier Martin <olivier.mar...@arm.com>
> wrote:
> > $
> > /work/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump
> > -S -D
> > Build/BeagleBoard/DEBUG_GCC48/ARM/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll
> >
> >
> >
> > FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet32(PcdFdBaseAddress) +
> > (EFI_PHYSICAL_ADDRESS)PcdGet32(PcdFdSize);
> >
> > 705c: 4b90 ldr r3, [pc, #576] ;
> > (72a0 <MemoryPeim+0x2a4>)
> >
> > 705e: 681b ldr r3, [r3, #0]
> >
> > 7060: 4618 mov r0, r3
> >
> > 7062: f04f 0100 mov.w r1, #0
> >
> > 7066: 4b8f ldr r3, [pc, #572] ; (72a4
> > <MemoryPeim+0x2a8>)
> >
> > 7068: 681b ldr r3, [r3, #0]
> >
> > 706a: 461a mov r2, r3
> >
> > 706c: f04f 0300 mov.w r3, #0
> >
> > (...)
> >
> > 72a0: 0000b4ec andeq fp, r0, ip, ror #9
> >
> > 72a4: 0000b4f0 strdeq fp, [r0], -r0
> >
> > (...)
> >
> > 0000b4ec <_gPcd_FixedAtBuild_PcdFdBaseAddress>:
> >
> > b4ec: 80008000 andhi r8, r0, r0
> >
> > 0000b4f0 <_gPcd_FixedAtBuild_PcdFdSize>:
> >
> > b4f0: 000b0000 andeq r0, fp, r0
> >
> > I noticed in an earlier email you mentioned ArmPlatformPrePiUniCore.lib. If
> > you want to look at the final ELF file, you should have a look at ‘.dll’. I
> > know the name is confusing... But ‘.dll’ is actually a ELF file!
>
> Thanks Olivier! The '.dll' dump looks similar to ^ and contains proper PCD
> values
> at the right address. The '.lib' however shows all the PCDs to be at 00000000:
>
> Disassembly of section .rodata._gPcd_FixedAtBuild_PcdFvBaseAddress:
>
> 00000000 <_gPcd_FixedAtBuild_PcdFvBaseAddress>:
> 0: 80008000 andhi r8, r0, r0
>
> Is it all right that these two addresses are different?
Yes if the global was an extern then the library (set of object files) would
contain an object relocation entry to let the linker know what filial value
ends up at this address.
Note: The object relocations are not the same set as the image relocations that
the EFI code supports in the PE/COFF libraries. The image relocations only have
to fixup addresses, but object relocations also need to resolve external
references.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/BasePeCoffLib/
Thanks,
Andrew Fish
> If so, what else sould I check
> to trace the fault?
>
> Thanks,
> Varad
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
