Great! Would you be willing to accept a patch that makes arch-x86_64.c handle that condition like the other arches?
-Shane On Fri, May 24, 2019 at 12:27 PM Khem Raj <raj.k...@gmail.com> wrote: > > > On 5/24/19 8:10 AM, Shane Peelar wrote: > > I did some reading into the sources in other architectures. The closest > > match, arch_i386.c, makes the write conditional as you say. > > So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c, > > |arch-s390.c, |arch-s390x.c, and |arch-ia64.c.|||||| > > |||||| > > |||||| > > Notably, |||||||arch-cris.c||||||| has the same assert as > > |||||||arch-x86_64.c||||||| instead of the conditional. > > > > The code roughly looks like follows:|||||||||||||| > > |||||||||||||| > > ||||||| > > ||||||| > > 1. Check for dso->info[DT_PLTGOT]. If it does not exist, return 0 > > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error > > 3. Look for the section named ".plt" in the ELF. > > 4. If the section cannot be found, return 0 > > 5. Otherwise, write the address of .plt + constant (dependent on arch) > > to got[1]|||||||||||||| > > |||||||||||||| > > ||||||| > > ||||||| > > In |||||||arch-x86_64.c and arch-cris.c|||||||, step (4) above is an > > assert:||||||| > > > > |||||||1. Check for dso->info[DT_PLTGOT]. If it does not exist, return 0 > > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error > > 3. Look for the section named ".plt" in the ELF. > > 4. Assert that the section was found > > 5. Write the address of .plt + constant (dependent on arch) to got[1] > > > > I tested out making the assert conditional and nothing seemed to break > > at least. > > ||||||| > > ||||||| > > It seems ok to me. > > > > > On Fri, May 24, 2019 at 12:08 AM Khem Raj <raj.k...@gmail.com > > <mailto:raj.k...@gmail.com>> wrote: > > > > > > > > On 5/23/19 7:53 PM, Shane Peelar wrote: > > > Any of them on the system pretty much, and yes they are also > > built with > > > -fno-plt. > > > > OK, I think its better to them conditionally check for .plt section, > > can you describe more of whats going on when sections are checked. > > > > > > > > On Thu, May 23, 2019 at 9:59 PM Khem Raj <raj.k...@gmail.com > > <mailto:raj.k...@gmail.com> > > > <mailto:raj.k...@gmail.com <mailto:raj.k...@gmail.com>>> wrote: > > > > > > > > > > > > On 5/23/19 8:05 AM, Shane Peelar wrote: > > > > Hi Everyone @ the Yocto project, > > > > > > > > I'm Shane Peelar, a PhD Candidate at the University of > > Windsor. > > > > I'm writing to you about prelink-cross, as part of the > > Yocto project. > > > > Specifically, I'm looking at using it with executables > > built using > > > > `-fno-plt` under GCC. > > > > I wasn't quite sure where to send this email to, so I > > figured I'd > > > try > > > > here. If there's a better place to send this, please let > > me know. > > > > > > > > Right now, prelink-cross seems to fail an assertion in > > > arch-x86_64.c, > > > > line 421, when > > > > using it with an executable built with `-fno-plt`: > > > > > > > > ... > > > > assert (i < dso->ehdr.e_shnum) > > > > ... > > > > > > > > This snippet seems to be looking for the ".plt" section > and, > > > since it > > > > can't find it, the assertion fires. This makes sense > > because in > > > > `-fno-plt` executables, the `.plt` section is missing > > entirely. > > > > I'm not an expert on ELF stuff, although I am learning > > quickly. It > > > > looks like > > > > this code wants to write into GOT[1] the address of ".plt" > > + 0x16 -- > > > > since ".plt" doesn't > > > > exist, does it make sense to just change this assert to an > if > > > statement > > > > like so: > > > > > > > > ... > > > > if (i < dso->ehdr.e_shnum) > > > > { ... } > > > > ... > > > > > > > > and skip over that part? Or is this a real error > > condition for > > > > prelink-cross and it really should not continue? The > > executable in > > > > question is also non-PIE, if that makes a difference. > > > > > > > > > > what shared libs is this linking to ? are they also built with > > > -fno-plt ? > > > > > > > Thanks for your time, > > > > Shane > > > > > > > > > >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
