[yocto] prelink-cross with -fno-plt

Shane Peelar lookatyouhacker at gmail.com
Sun Jun 2 21:50:03 PDT 2019


Will do, thanks!

On Sat, Jun 1, 2019, 3:50 PM Mark Hatle, <mark.hatle at windriver.com> wrote:

> Thanks, this shows that the prelinking is still working in this case.
> I'll get
> you patch queued up.  If you don't see any progress on it this coming week,
> please feel free to remind me.
>
> --Mark
>
> On 5/29/19 1:42 PM, Shane Peelar wrote:
> > Hi Mark,
> >
> > Thank you for your reply and no problem -- I chose to benchmark ssh-add
> with
> > it.  It contains no `.plt`.
> >
> > The results are as follows:
> >
> > Without prelink (ran prelink -auv):
> >
> >      26019:
> >      26019:     runtime linker statistics:
> >      26019:       total startup time in dynamic loader: 1321674 cycles
> >      26019:                 time needed for relocation: 797948 cycles
> (60.3%)
> >      26019:                      number of relocations: 624
> >      26019:           number of relocations from cache: 3
> >      26019:             number of relative relocations: 9691
> >      26019:                time needed to load objects: 389972 cycles
> (29.5%)
> > Could not open a connection to your authentication agent.
> >      26019:
> >      26019:     runtime linker statistics:
> >      26019:                final number of relocations: 630
> >      26019:     final number of relocations from cache: 3
> >
> > With prelink (ran prelink -av):
> >
> >       1930:
> >       1930:     runtime linker statistics:
> >       1930:       total startup time in dynamic loader: 462288 cycles
> >       1930:                 time needed for relocation: 48730 cycles
> (10.5%)
> >       1930:                      number of relocations: 7
> >       1930:           number of relocations from cache: 134
> >       1930:             number of relative relocations: 0
> >       1930:                time needed to load objects: 286076 cycles
> (61.8%)
> > Could not open a connection to your authentication agent.
> >       1930:
> >       1930:     runtime linker statistics:
> >       1930:                final number of relocations: 9
> >       1930:     final number of relocations from cache: 134
> >
> > I also tested against execstack, which for sure had the assertion fire
> on.
> > Without prelink:
> >
> >      27736:
> >      27736:     runtime linker statistics:
> >      27736:       total startup time in dynamic loader: 1955954 cycles
> >      27736:                 time needed for relocation: 755440 cycles
> (38.6%)
> >      27736:                      number of relocations: 247
> >      27736:           number of relocations from cache: 3
> >      27736:             number of relative relocations: 1353
> >      27736:                time needed to load objects: 710384 cycles
> (36.3%)
> > /usr/bin/execstack: no files given
> >      27736:
> >      27736:     runtime linker statistics:
> >      27736:                final number of relocations: 251
> >      27736:     final number of relocations from cache: 3
> >
> > With prelink:
> >
> >       3268:
> >       3268:     runtime linker statistics:
> >       3268:       total startup time in dynamic loader: 1421206 cycles
> >       3268:                 time needed for relocation: 199396 cycles
> (14.0%)
> >       3268:                      number of relocations: 3
> >       3268:           number of relocations from cache: 88
> >       3268:             number of relative relocations: 0
> >       3268:                time needed to load objects: 696886 cycles
> (49.0%)
> > /usr/bin/execstack: no files given
> >       3268:
> >       3268:     runtime linker statistics:
> >       3268:                final number of relocations: 5
> >       3268:     final number of relocations from cache: 88
> >
> > So, it looks like prelink is working on these :)
> >
> > On Tue, May 28, 2019 at 2:57 PM Mark Hatle <mark.hatle at windriver.com
> > <mailto:mark.hatle at windriver.com>> wrote:
> >
> >     Sorry for my delayed reply.  I was out on a business trip.
> >
> >     Did you try this with the ld.so statistics to see if the relocations
> were indeed
> >     reduced at runtime?
> >
> >     One of my worries with these changes (since I am not an ELF expert
> either) is
> >     that we make a change that doesn't actually do anything -- but
> people expect
> >     it to.
> >
> >     $ LD_DEBUG=help /lib/ld-linux.so.2
> >     Valid options for the LD_DEBUG environment variable are:
> >
> >       libs        display library search paths
> >       reloc       display relocation processing
> >       files       display progress for input file
> >       symbols     display symbol table processing
> >       bindings    display information about symbol binding
> >       versions    display version dependencies
> >       scopes      display scope information
> >       all         all previous options combined
> >       statistics  display relocation statistics
> >       unused      determined unused DSOs
> >       help        display this help message and exit
> >
> >     To direct the debugging output into a file instead of standard output
> >     a filename can be specified using the LD_DEBUG_OUTPUT environment
> variable.
> >
> >     I believe that it's the 'statistics' option.
> >
> >     LD_DEBUG=statistics <executable that's been prelinked>
> >
> >     Should result in something like:
> >
> >         128820:     runtime linker statistics:
> >         128820:       total startup time in dynamic loader: 1974661
> cycles
> >         128820:                 time needed for relocation: 354639
> cycles (17.9%)
> >         128820:                      number of relocations: 90
> >         128820:           number of relocations from cache: 3
> >         128820:             number of relative relocations: 1201
> >         128820:                time needed to load objects: 1303654
> cycles (66.0%)
> >         128820:
> >         128820:     runtime linker statistics:
> >         128820:                final number of relocations: 94
> >         128820:     final number of relocations from cache: 3
> >
> >     If prelink is working, the number of relocations (relative or
> otherwise) will be
> >     significantly reduced from the original non-relocated version.
> >
> >     If you can run this test, it would give me the assurance that the
> patch is safe,
> >     and I'll get it incorporated into the prelink-cross sources.
> >
> >     --Mark
> >
> >     On 5/25/19 2:53 PM, Shane Peelar wrote:
> >     > Patch is attached.  Thank you!
> >     >
> >     > On Sat, May 25, 2019 at 2:30 AM Khem Raj <raj.khem at gmail.com
> >     <mailto:raj.khem at gmail.com>
> >     > <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>> wrote:
> >     >
> >     >     On Fri, May 24, 2019 at 6:58 PM Shane Peelar
> >     <lookatyouhacker at gmail.com <mailto:lookatyouhacker at gmail.com>
> >     >     <mailto:lookatyouhacker at gmail.com <mailto:
> lookatyouhacker at gmail.com>>>
> >     wrote:
> >     >     >
> >     >     > Great!  Would you be willing to accept a patch that makes
> arch-x86_64.c
> >     >     handle that condition like the other arches?
> >     >     >
> >     >
> >     >     yes certainly.
> >     >
> >     >     > -Shane
> >     >     >
> >     >     > On Fri, May 24, 2019 at 12:27 PM Khem Raj <
> raj.khem at gmail.com
> >     <mailto:raj.khem at gmail.com>
> >     >     <mailto:raj.khem at gmail.com <mailto:raj.khem at 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.khem at gmail.com
> >     <mailto:raj.khem at gmail.com>
> >     >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
> >     >     >> > <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>
> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at 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.khem at gmail.com <mailto:raj.khem at gmail.com>
> >     >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
> >     >     >> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com
> >
> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>>
> >     >     >> >      > <mailto:raj.khem at gmail.com <mailto:
> raj.khem at gmail.com>
> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
> >     >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>
> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at 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
> >     >     >> >      >      >
> >     >     >> >      >
> >     >     >> >
> >     >
> >     >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190602/4e69d965/attachment-0001.html>


More information about the yocto mailing list