On Thu, Aug 03, 2006 at 12:35:31PM -0600, Eric W. Biederman wrote:
> 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?
>
Eric,
As I already mentioned in the mail when you retrive the symbol for
R_PPC64_TOC relocation type it always retrieves the first symbol in
the symbol table entry ie STN_UNDEF , because ELF64_R_SYM(reloc.r_info)
is always zero.
Better we can use ELF64_R_TYPE(reloc.r_info) which gives the relocation
type and in this case it is R_PPC64_TOC. So can we do a check like this?
type = ELF64_ST_TYPE(sym.st_info);
if ((sym.st_shndx == STN_UNDEF) && (type != R_PPC64_TOC))
die("Undefined symbol: %s\n", strtab + sym.st_name);
R_PPC64_TOC is 51. Only two other architectures also have 51 in their
list of reloction types. 1. R_SPARC_M44 and 2. R_390_TLS_LE64.
Regards,
Mohan.
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
