Mohan Kumar M <[EMAIL PROTECTED]> writes:
> 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.
I guess I did not see that implying anything about sym.st_info.
Except possibly that it is 0. Which would just be STT_NOTYPE which
I don't really care about.
> 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.
I would be willing if I can clearly understand why the other more
general test has no hope of succeeding.
If we can solve this cleanly I want that. Otherwise we can have
a test for ppc64 and TOC.
Eric
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
