Am 06/21/2011 07:19 PM, schrieb Drasko DRASKOVIC:
>
>> Perhaps bfd library?
> Yes, that would be the right place, but I hoped to avoid further digging ;).
>
> Here is something interesting, from the gdb's src/bfd/elf.c, line 963
> (and it is related to one of the posts I mentioned previously) :
>
> if ((flags & SEC_ALLOC) != 0)
> {
> Elf_Internal_Phdr *phdr;
> unsigned int i, nload;
>
> /* Some ELF linkers produce binaries with all the program header
> p_paddr fields zero. If we have such a binary with more than
> one PT_LOAD header, then leave the section lma equal to vma
> so that we don't create sections with overlapping lma. */
> phdr = elf_tdata (abfd)->phdr;
> for (nload = 0, i = 0; i < elf_elfheader (abfd)->e_phnum; i++, phdr++)
> if (phdr->p_paddr != 0)
> break;
> else if (phdr->p_type == PT_LOAD && phdr->p_memsz != 0)
> ++nload;
> if (i >= elf_elfheader (abfd)->e_phnum && nload > 1)
> return TRUE;
>
>
> Basically, BFD (and thus GDB) knows a workaround - which seems to be
> the same thing I did - if your ELF has p_paddr == 0, make it equal to
> p_vaddr, and use this as LMA.
Um - unless I misread the code, there is an important difference:
In the gdb code, the workaround only kicks in if *all* p_paddr from all
sections are zero, while your patch will kick in if a single section's
p_paddr is zero. The gdb solution seems safer to me.
> ARM ELF compliant linker _must_ produce ELF with p_paddr = 0.
> It seems like GNU ld (which probably uses these workarounds from BFD)
> equals p_paddr to p_vaddr, so that the problem is masked, and OpenOCD
> is using p_paddr.
> Once you stumble upon ELF linked with some ARM ELF compliant liker,
> OpenOCD will go wrong, while GDB will do fine by using the upper
> mentioned procedure.
>
> My opinion is that we currently have *broken* OpenOCD load_image
> behavior (works with GNU ld, though), and that we can not make it any
> worst with this patch.
Yes, we can: loading code at 0 may fail.
> I also opened the question - is there a valid ELF that has p_paddr 0x0
> and p_vaddr != 0. Obviously, regarding the upper mentioned code from
> BFD, production of such ELF is not possible with GNU ld, because it
> will keep p_paddr_valid flag at FALSE and equalize p_paddr to p_vaddr
> at some point...
Address 0 is a valid starting address - I know systems with RAM or FLASH
at 0, so code with p_paddr==0 for one section is a valid case.
I have no objection against implementing the gdb workaround (checking if
*all* sections are zero)
cu
Michael
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
