On Tue, Jun 21, 2011 at 6:18 PM, Øyvind Harboe <oyvind.har...@zylin.com> wrote:
>> http://www.mail-archive.com/bug-grub@gnu.org/msg00715.html
>
> From 1999? Time flies, eh?
For BDF time flies slowely ;)... Anyway, I gave this just as example
of implementation (as I underlined, btw.), but real reasons are
explained in other posts.
>> What do you think ?
>
> Until we understand this better, I think we can wait with applying the
> patch.
To understand this better all the posts I mentioned deserve reading.
The subject is not so obvious and deserves a little study..
> Look at gdb source code?
I gave an example from the U-Boot sources, ARM ELF specification
(which is clearly not respected), bunh of posts, etc... Thought that
that would be more than enough for someone who want to dig into the
subject.
> 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.
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.
I hope that this clarifies my assumptions and gives more material for
others to jump in with suggestions.
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...
Let's wait for some more responses on this list and I can post the
question on Binutils dev list, to clear this subject...
BR,
Drasko
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
