On Tue, Jun 21, 2011 at 7:35 PM, Michael Schwingen <[email protected]> wrote: > 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.
Hi Michael, yes, you got the point. BFD seems to be allowing one_and_only_one p_paddr to be zero for loadable segments. Here is some posts on this : http://lists.gnu.org/archive/html/bug-gnu-utils/2002-02/msg00098.html and http://www.opensource.apple.com/source/binutils/binutils-36/src/bfd/elf.c >> 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 mentioned this as a special question, I agree on this. If virtual address is != 0, that means you linked for this address. Normally, you would expect GDB to load binary to it's execution address. If you do not want to do this (i.e. you have pic code and want to run binaries from addresses for which they are not linked) then you know exactly what you are doing and you are providing load address explicitly to load_image command as an argument... I agree on this, things might break. >> 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) Yes, I think that would be the most correct way. BR, Drasko _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
