Mohan Kumar M <[EMAIL PROTECTED]> writes:
> 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.
Ok. We are close. All of the relocations work as long as value is
computed correctly.
The final question then is can we limit the type of symbols for which
we support an SHN_UNDEF value. So we can still catch programmers errors.
I think if we simply don't support STT_OBJECT, STT_FUNC, and STT_TLS,
we will catch all of the problems I an worried about while still handling
the relocations in your opd section. I threw in STT_NOTYPE for good
measure as I don't think that case should ever happen in practice.
Does this patch work for you?
diff --git a/kexec/kexec-elf-rel.c b/kexec/kexec-elf-rel.c
index b55d2c2..999d92a 100644
--- a/kexec/kexec-elf-rel.c
+++ b/kexec/kexec-elf-rel.c
@@ -363,42 +363,36 @@ #ifdef DEBUG
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?
+ /* Don't support weak symbols in purgatory.
+ * They usually indicate that some one has fogotten
+ * to define a variable, or a function.
*/
- /*
+ type = ELF32_ST_TYPE(sym.st_info);
+ if ((sym.st_shndx == STN_UNDEF) && (
+ (type == STT_NOTYPE) || (type == STT_OBJECT) ||
+ (type == STT_FUNC) || (type = STT_TLS)))
die("Undefined symbol: %s\n",
strtab + sym.st_name);
- */
- continue;
- }
+
sec_base = 0;
- if (sym.st_shndx == SHN_COMMON) {
+ value = sym.st_value;
+ 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)
+ value = 0;
+ else if (sym.st_shndx == SHN_ABS)
sec_base = 0;
- }
- else if (sym.st_shndx > ehdr->e_shnum) {
+ else if (sym.st_shndx > ehdr->e_shnum)
die("Invalid section: %d for symbol %s\n",
sym.st_shndx,
strtab + sym.st_name);
- }
- else {
+ 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);
#endif
- value = sym.st_value;
value += sec_base;
value += rel.r_addend;
machine_apply_elf_rel(ehdr, rel.r_type,
@@ -463,7 +457,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",
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
