On 28/11/2011 13.18, Filippo ARCIDIACONO wrote: > Hi Mike, > >> -----Original Message----- >> From: Mike Frysinger [mailto:vap...@gentoo.org] >> Sent: Sunday, November 27, 2011 9:12 AM >> To: uclibc@uclibc.org; filippo.arcidiac...@st.com; >> carmelo.amor...@st.com >> Subject: prelink breaks fdpic support in a bunch of places >> >> there seems to be a bunch of changes that the associated changelog does >> not seem to cover. so i don't know if they were changed on purpose, by >> accident, etc... >> >>> commit a33796043bdef5345bc00a528c942f91a87af8e9 >>> ldso: Add runtime prelink support >>> >>> _dl_load_elf_shared_library(int secure,...) ... >>> - DL_LOADADDR_TYPE lib_loadaddr; >>> + DL_LOADADDR_TYPE lib_loadaddr = 0; >> >> why is this necessary ? nothing else in this func changed. you can't >> assign directly to a variable of type DL_LOADADDR_TYPE. > > You are right. I missed DL_LOADADDR_TYPE for archs not sh. > >> >>> int _dl_fixup(struct dyn_elf *rpnt, struct r_scope_elem *scope, int >>> now_flag) ... >>> - elf_machine_relative(tpnt->loadaddr, reloc_addr, relative_count); >>> + if (tpnt->loadaddr >>> +#ifdef __LDSO_PRELINK_SUPPORT__ >>> + || (!tpnt->dynamic_info[DT_GNU_PRELINKED_IDX]) >>> +#endif >>> + ) >>> + elf_machine_relative(tpnt->loadaddr, reloc_addr, >> relative_count); >> >> why is tpn->loadaddr now being checked ? > >
Apart the issue with archs where loadaddr is not a plan address value, I'm pretty sure that we added the check as a sort of optimisation, assuming that elf_machine_relative should not be called if loadaddr was 0, but indeed there are some architecture (that have RELA relocations) for which that function should be called in any case. I suspect that this is one of the possible problem we introduced and that Khem is seeing. We are posting a experimental patch. Carmelo _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc