Some more posts on this interesting topic : http://blackfin.uclinux.org/gf/project/u-boot/tracker/?action=TrackerItemEdit&tracker_item_id=642 http://lists.gnu.org/archive/html/bug-gnu-utils/2002-08/msg00324.html
Seems to me that solution proposed in the patch is OK, but I am still wondering : is there a case on some architectures where you can have valid load physicall address of 0x0 (i.e. if you want to load U-Boot at the address 0x0, and it has normally different execution address (vma), as it is linked to address where it will auto-relocate, and only the beginning is executed PIC code executed from addr 0x0) ? This is the only case (if exists) that this patch will not handle, but will go for vma addr (i.e. will load U-Boot at the address for which it was compiled to run after auto-relocation, not at the address where this is supposed, 0x0). BR, Drasko On Tue, Jun 21, 2011 at 2:59 PM, Drasko DRASKOVIC <drasko.drasko...@gmail.com> wrote: > Hi all, > yesterday I run into the ELF like this : > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x000074 0x00008000 0x00000000 0xe1f18 0xe1f18 RWE 0x1 > LOAD 0x0e1f8c 0x0060f028 0x00000000 0x1103f 0x1103f RWE 0x1 > > As it can be seen from the readelf output, PhysAddress of the segments > is 0x0, and this posed problems for the load_image command of OpenOCD. > However, arm GDB was very happy to load it, loading section by section > at appropriate virtual addresses. > > I did some investigation, and I found out (from ELF specification) : > p_vaddr : This member gives the virtual address at which the first > byte of the segment resides in > memory. > p_paddr : On systems for which physical addressing is relevant, this > member is reserved for the > segment’s physical address. Because System V ignores physical > addressing for application > programs, this member has unspecified contents for executable files and shared > objects. > > Then I run into these posts : > http://cygwin.com/ml/binutils/2002-09/msg00516.html > http://lists.gnu.org/archive/html/bug-gnu-utils/2002-08/msg00319.html > > ARM ELF specification seems to be stating explicitly that p_paddr in > the Program Header Table should be put to zero for all Text, Data and > BSS segments: > p_vaddr - load address of the segment > p_paddr - 0 > > Further on, in "Scatter-loaded Executables" part of the same document it says > : > sh_addr: same as p_vaddr of corresponding Segment > > The p_vaddr field of each Segment of a scatter-loaded Executable is > the load address > of the Segment, which need not necessarily be its execution address. > Startup code can > move (part of) a Segment to its execution address using the symbols: > Load$$reg$$Base > Image$$reg$$Base > Image$$reg$$Length > as described in the Software Development Toolkit User Guide. > > I am guessing that GDB uses this method and always takes p_vaddr > (OpenOCD is not consistent to GDB in this case). > > To conclude, I crafted a trivial patch which will impose taking > p_vaddr as the load destination of the segment whenever p_paddr is > 0x0. > I was a bit afraid to go for p_vaddr only_and_always, but left this as > a solution, because I do not know the impact on other architectures, > so I followed this post : > http://www.mail-archive.com/bug-grub@gnu.org/msg00715.html > > What do you think ? > > Best regards, > Drasko > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
