[U-Boot-Users] Is there a redundant check in function "load_elf_image" in common/cmd_elf.c?
Hi
I have been trying to use the "bootelf" command of u-boot. I noticed that if the program text is based at address 0x0 the command fails because the .text section does not copied by the load_elf_image function (even though the correct entry point is returned by load_elf_image). The same test program I have boots correctly if the .text section is placed elsewhere.
The reason the .text section is not copied is because it it is skipped due to the block.
if (!(shdr->sh_flags & SHF_ALLOC) || shdr->sh_addr == 0 || shdr->sh_size == 0) { continue; }
because shdr->sh_addr = 0.
I put in a few printfs to print information for each section, and I can see that various debug sections, symbol table etc have sh_addr = 0 and certainly they shouldn't be loaded, but the clause "!(shdr->sh_flags & SHF_ALLOC)" takes care of these anyway - (admittedly only for my particular ELF!). So I removed the "shdr->sh_addr == 0" check, recompiled u-boot (which for me is not based at 0x0!) and was able to boot my ELF.
Perhaps the "shdr->sh_addr == 0" clause filters out sections for other types of ELFs - but should another mechanism be used to remove them from the list? In the case of my ARM 926ejs target the .text needs to be based at 0x0 since the interrupt vectors have to be place at 0x0.
This is my first posting here, I apologize in advance if there is an obvious answer to my question.
Ali
On Thu, 6 Dec 2007 14:36:57 -0800 "Ali Rouhi" rouhi.ali@gmail.com wrote:
if (!(shdr->sh_flags & SHF_ALLOC) || shdr->sh_addr == 0 || shdr->sh_size == 0) { continue; }
This looks bogus for several reasons. First, there's nothing wrong with placing a loadable section at address 0. Second, why is a _loader_ looking at the section header anyway? Loaders are supposed to look at the program header, while the section header is for linkers and debuggers.
The latter issue isn't that serious since the section header contains all the needed information, but an ELF file without a section header is still a valid ELF file that the loader should know how to deal with.
So I removed the "shdr->sh_addr == 0" check, recompiled u-boot (which for me is not based at 0x0!) and was able to boot my ELF.
I think that change makes sense; care to submit a patch? Although beware that when your application is loaded at address 0, NULL pointers can't really be used as NULL pointers anymore since they may point to valid data.
Haavard
Hi Haavard
A patch is attached. However your email jogged my memory. Before I posted my original message I did a search on the archive and it seems a patch for using program headers for loading was submitted over a year ago:
http://sourceforge.net/mailarchive/message.php?msg_id=BCD6BEF0CD0AE546B84C18...
I haven't looked at it, but given what you wrote it may be a superior method for fixing the problem.
Best Regards Ali
On Dec 7, 2007 1:10 AM, Haavard Skinnemoen hskinnemoen@atmel.com wrote:
On Thu, 6 Dec 2007 14:36:57 -0800 "Ali Rouhi" rouhi.ali@gmail.com wrote:
if (!(shdr->sh_flags & SHF_ALLOC) || shdr->sh_addr == 0 || shdr->sh_size == 0) { continue; }This looks bogus for several reasons. First, there's nothing wrong with placing a loadable section at address 0. Second, why is a _loader_ looking at the section header anyway? Loaders are supposed to look at the program header, while the section header is for linkers and debuggers.
The latter issue isn't that serious since the section header contains all the needed information, but an ELF file without a section header is still a valid ELF file that the loader should know how to deal with.
So I removed the "shdr->sh_addr == 0" check, recompiled u-boot (which for me is not based at 0x0!) and was able to boot my ELF.
I think that change makes sense; care to submit a patch? Although beware that when your application is loaded at address 0, NULL pointers can't really be used as NULL pointers anymore since they may point to valid data.
Haavard
participants (2)
-
Ali Rouhi -
Haavard Skinnemoen