On Wed, Aug 02, 2006 at 10:04:55AM -0600, Eric W. Biederman wrote:
>
> I would like to avoid that. We seem to be able to get the symbol
> correctly. I believe we can check the type of the symbol.
>
> But regardless of checking the type of the symbol if you comment out
> my sanity check (and not put a continue in there). Can you properly
> process this relocation type?
Hi Eric,
I tried as you suggested to process the relocation for sym.st_shndx ==
STN_UNDEF. Relocation code works. It is a R_PPC64_TOC relocation method
and it uses the TOC value for relocation. It does not use sym.st_value.
Note about STN_UNDEF for relocation from ELF spec.
r_info:
This member gives both the symbol table index with respect to which the
relocation must be made, and the type of relocation to apply. For
example, a call instruction's relocation entry would hold the symbol
table index of the function being called. If the index is STN_UNDEF, the
undefined symbol index, the relocation uses 0 as the "symbol value.''
Relocation types are processor-specific; descriptions of their behavior
appear in the processor supplement.
I am new to git. So if there is any problem with this patch generation,
let me know.
Here is the patch.
Signed-off-by: Mohan Kumar <[EMAIL PROTECTED]>
If the index of relocation entry symbol is STN_UNDEF, the undefined symbol
index, the relocation uses 0 as the symbol value. This case is not handled
properly in kexec-tools relocation code. This patch fixes this issue.
---
kexec/kexec-elf-rel.c | 35 +++++++++--------------------------
1 files changed, 9 insertions(+), 26 deletions(-)
f9ce6d734552237a0fe9515f4243cad9d5dff7e2
diff --git a/kexec/kexec-elf-rel.c b/kexec/kexec-elf-rel.c
index b55d2c2..e7b3426 100644
--- a/kexec/kexec-elf-rel.c
+++ b/kexec/kexec-elf-rel.c
@@ -363,37 +363,20 @@ int elf_rel_load(struct mem_ehdr *ehdr,
sym.st_size);
#endif
- if (sym.st_shndx == STN_UNDEF) {
- /*
- * NOTE: ppc64 elf .ro shows up a UNDEF section.
- * From Elf 1.2 Spec:
- * Relocation Entries: If the index is STN_UNDEF,
- * the undefined symbol index, the relocation uses 0
- * as the "symbol value".
- * So, is this really an error condition to flag die?
- */
- /*
- die("Undefined symbol: %s\n",
- strtab + sym.st_name);
- */
- continue;
- }
sec_base = 0;
- if (sym.st_shndx == SHN_COMMON) {
+ if (sym.st_shndx == SHN_COMMON)
die("symbol: '%s' in common section\n",
strtab + sym.st_name);
- }
- else if (sym.st_shndx == SHN_ABS) {
+ else if (sym.st_shndx == SHN_UNDEF) {
sec_base = 0;
- }
- else if (sym.st_shndx > ehdr->e_shnum) {
+ sym.st_value = 0;
+ } else if (sym.st_shndx == SHN_ABS)
+ sec_base = 0;
+ else if (sym.st_shndx > ehdr->e_shnum)
die("Invalid section: %d for symbol %s\n",
- sym.st_shndx,
- strtab + sym.st_name);
- }
- else {
+ sym.st_shndx, strtab + sym.st_name);
+ else
sec_base = ehdr->e_shdr[sym.st_shndx].sh_addr;
- }
#ifdef DEBUG
fprintf(stderr, "sym: %s value: %lx addr: %lx\n",
strtab + sym.st_name, value, address);
@@ -463,7 +446,7 @@ int elf_rel_find_symbol(struct mem_ehdr
if (strcmp(strtab + sym.st_name, name) != 0) {
continue;
}
- if ((sym.st_shndx == STN_UNDEF) ||
+ if ((sym.st_shndx == SHN_UNDEF) ||
(sym.st_shndx > ehdr->e_shnum))
{
die("Symbol: %s has Bad section index %d\n",
--
1.0.GIT
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
