All of lore.kernel.org
 help / color / mirror / Atom feed
* prelink-cross with -fno-plt
@ 2019-05-23 15:05 Shane Peelar
  2019-05-24  1:59 ` Khem Raj
  0 siblings, 1 reply; 13+ messages in thread
From: Shane Peelar @ 2019-05-23 15:05 UTC (permalink / raw)
  To: yocto

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

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.

Thanks for your time,
Shane

[-- Attachment #2: Type: text/html, Size: 1683 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-23 15:05 prelink-cross with -fno-plt Shane Peelar
@ 2019-05-24  1:59 ` Khem Raj
  2019-05-24  2:53   ` Shane Peelar
  0 siblings, 1 reply; 13+ messages in thread
From: Khem Raj @ 2019-05-24  1:59 UTC (permalink / raw)
  To: Shane Peelar, yocto



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
> 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-24  1:59 ` Khem Raj
@ 2019-05-24  2:53   ` Shane Peelar
  2019-05-24  4:08     ` Khem Raj
  0 siblings, 1 reply; 13+ messages in thread
From: Shane Peelar @ 2019-05-24  2:53 UTC (permalink / raw)
  To: Khem Raj; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

Any of them on the system pretty much, and yes they are also built with
-fno-plt.

On Thu, May 23, 2019 at 9:59 PM Khem Raj <raj.khem@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
> >
>

[-- Attachment #2: Type: text/html, Size: 2370 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-24  2:53   ` Shane Peelar
@ 2019-05-24  4:08     ` Khem Raj
  2019-05-24 15:10       ` Shane Peelar
  0 siblings, 1 reply; 13+ messages in thread
From: Khem Raj @ 2019-05-24  4:08 UTC (permalink / raw)
  To: Shane Peelar; +Cc: yocto



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@gmail.com 
> <mailto:raj.khem@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
>      >
> 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-24  4:08     ` Khem Raj
@ 2019-05-24 15:10       ` Shane Peelar
  2019-05-24 16:27         ` Khem Raj
  0 siblings, 1 reply; 13+ messages in thread
From: Shane Peelar @ 2019-05-24 15:10 UTC (permalink / raw)
  To: Khem Raj; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

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.


On Fri, May 24, 2019 at 12:08 AM Khem Raj <raj.khem@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@gmail.com
> > <mailto:raj.khem@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
> >      >
> >
>

[-- Attachment #2: Type: text/html, Size: 6013 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-24 15:10       ` Shane Peelar
@ 2019-05-24 16:27         ` Khem Raj
  2019-05-25  1:58           ` Shane Peelar
  0 siblings, 1 reply; 13+ messages in thread
From: Khem Raj @ 2019-05-24 16:27 UTC (permalink / raw)
  To: Shane Peelar; +Cc: yocto



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@gmail.com 
> <mailto:raj.khem@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@gmail.com
>     <mailto:raj.khem@gmail.com>
>      > <mailto:raj.khem@gmail.com <mailto:raj.khem@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
>      >      >
>      >
> 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-24 16:27         ` Khem Raj
@ 2019-05-25  1:58           ` Shane Peelar
  2019-05-25  6:30             ` Khem Raj
  0 siblings, 1 reply; 13+ messages in thread
From: Shane Peelar @ 2019-05-25  1:58 UTC (permalink / raw)
  To: Khem Raj; +Cc: yocto

[-- Attachment #1: Type: text/plain, Size: 4838 bytes --]

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.khem@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@gmail.com
> > <mailto:raj.khem@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@gmail.com
> >     <mailto:raj.khem@gmail.com>
> >      > <mailto:raj.khem@gmail.com <mailto:raj.khem@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
> >      >      >
> >      >
> >
>

[-- Attachment #2: Type: text/html, Size: 6901 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-25  1:58           ` Shane Peelar
@ 2019-05-25  6:30             ` Khem Raj
  2019-05-25 12:53               ` Shane Peelar
  0 siblings, 1 reply; 13+ messages in thread
From: Khem Raj @ 2019-05-25  6:30 UTC (permalink / raw)
  To: Shane Peelar; +Cc: Yocto Project

On Fri, May 24, 2019 at 6:58 PM Shane Peelar <lookatyouhacker@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@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@gmail.com
>> > <mailto:raj.khem@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@gmail.com
>> >     <mailto:raj.khem@gmail.com>
>> >      > <mailto:raj.khem@gmail.com <mailto:raj.khem@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
>> >      >      >
>> >      >
>> >


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-25  6:30             ` Khem Raj
@ 2019-05-25 12:53               ` Shane Peelar
  2019-05-28 18:57                 ` Mark Hatle
  0 siblings, 1 reply; 13+ messages in thread
From: Shane Peelar @ 2019-05-25 12:53 UTC (permalink / raw)
  To: Khem Raj; +Cc: Yocto Project


[-- Attachment #1.1: Type: text/plain, Size: 5473 bytes --]

Patch is attached.  Thank you!

On Sat, May 25, 2019 at 2:30 AM Khem Raj <raj.khem@gmail.com> wrote:

> On Fri, May 24, 2019 at 6:58 PM Shane Peelar <lookatyouhacker@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@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@gmail.com
> >> > <mailto:raj.khem@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@gmail.com
> >> >     <mailto:raj.khem@gmail.com>
> >> >      > <mailto:raj.khem@gmail.com <mailto:raj.khem@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
> >> >      >      >
> >> >      >
> >> >
>

[-- Attachment #1.2: Type: text/html, Size: 8381 bytes --]

[-- Attachment #2: 0001-arch-x86_64.c-Make-assert-conditional.patch --]
[-- Type: text/x-patch, Size: 952 bytes --]

From 2cc1d58caaba994855516b50d5af057854c94fe8 Mon Sep 17 00:00:00 2001
From: Shane Peelar <lookatyouhacker@gmail.com>
Date: Sat, 25 May 2019 08:45:45 -0400
Subject: [PATCH] arch-x86_64.c: Make assert conditional

Make the assert in arch_prelink a condition instead of an assert,
keeping things consistent with the other arches.  This makes
prelink not bail out on `-fno-plt` executables.

Signed-off-by: Shane Peelar <lookatyouhacker@gmail.com>
---
 src/arch-x86_64.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/arch-x86_64.c b/src/arch-x86_64.c
index 2f6c551..aa739e6 100644
--- a/src/arch-x86_64.c
+++ b/src/arch-x86_64.c
@@ -418,7 +418,8 @@ x86_64_arch_prelink (struct prelink_info *info)
 			 ".plt"))
 	break;
 
-      assert (i < dso->ehdr.e_shnum);
+      if (i == dso->ehdr.e_shnum)
+	return 0;
       data = dso->shdr[i].sh_addr + 0x16;
       write_le64 (dso, dso->info[DT_PLTGOT] + 8, data);
     }
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-25 12:53               ` Shane Peelar
@ 2019-05-28 18:57                 ` Mark Hatle
  2019-05-29 18:42                   ` Shane Peelar
  0 siblings, 1 reply; 13+ messages in thread
From: Mark Hatle @ 2019-05-28 18:57 UTC (permalink / raw)
  To: Shane Peelar, Khem Raj; +Cc: Yocto Project

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@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
> 
>     On Fri, May 24, 2019 at 6:58 PM Shane Peelar <lookatyouhacker@gmail.com
>     <mailto:lookatyouhacker@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@gmail.com
>     <mailto:raj.khem@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@gmail.com
>     <mailto:raj.khem@gmail.com>
>     >> > <mailto:raj.khem@gmail.com <mailto:raj.khem@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@gmail.com
>     <mailto:raj.khem@gmail.com>
>     >> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
>     >> >      > <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>
>     <mailto:raj.khem@gmail.com <mailto:raj.khem@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
>     >> >      >      >
>     >> >      >
>     >> >
> 
> 



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-28 18:57                 ` Mark Hatle
@ 2019-05-29 18:42                   ` Shane Peelar
  2019-06-01 22:50                     ` Mark Hatle
  0 siblings, 1 reply; 13+ messages in thread
From: Shane Peelar @ 2019-05-29 18:42 UTC (permalink / raw)
  To: Mark Hatle; +Cc: Yocto Project

[-- Attachment #1: Type: text/plain, Size: 12236 bytes --]

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@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@gmail.com
> > <mailto:raj.khem@gmail.com>> wrote:
> >
> >     On Fri, May 24, 2019 at 6:58 PM Shane Peelar <
> lookatyouhacker@gmail.com
> >     <mailto:lookatyouhacker@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@gmail.com
> >     <mailto:raj.khem@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@gmail.com
> >     <mailto:raj.khem@gmail.com>
> >     >> > <mailto:raj.khem@gmail.com <mailto:raj.khem@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@gmail.com
> >     <mailto:raj.khem@gmail.com>
> >     >> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
> >     >> >      > <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>
> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@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
> >     >> >      >      >
> >     >> >      >
> >     >> >
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 17525 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-05-29 18:42                   ` Shane Peelar
@ 2019-06-01 22:50                     ` Mark Hatle
  2019-06-03  4:50                       ` Shane Peelar
  0 siblings, 1 reply; 13+ messages in thread
From: Mark Hatle @ 2019-06-01 22:50 UTC (permalink / raw)
  To: Shane Peelar; +Cc: Yocto Project

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@windriver.com
> <mailto:mark.hatle@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@gmail.com
>     <mailto:raj.khem@gmail.com>
>     > <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>> wrote:
>     >
>     >     On Fri, May 24, 2019 at 6:58 PM Shane Peelar
>     <lookatyouhacker@gmail.com <mailto:lookatyouhacker@gmail.com>
>     >     <mailto:lookatyouhacker@gmail.com <mailto:lookatyouhacker@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@gmail.com
>     <mailto:raj.khem@gmail.com>
>     >     <mailto:raj.khem@gmail.com <mailto:raj.khem@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@gmail.com
>     <mailto:raj.khem@gmail.com>
>     >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
>     >     >> > <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>
>     <mailto:raj.khem@gmail.com <mailto:raj.khem@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@gmail.com <mailto:raj.khem@gmail.com>
>     >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
>     >     >> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>
>     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>>
>     >     >> >      > <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>
>     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
>     >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>
>     <mailto:raj.khem@gmail.com <mailto:raj.khem@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
>     >     >> >      >      >
>     >     >> >      >
>     >     >> >
>     >
>     >
> 



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: prelink-cross with -fno-plt
  2019-06-01 22:50                     ` Mark Hatle
@ 2019-06-03  4:50                       ` Shane Peelar
  0 siblings, 0 replies; 13+ messages in thread
From: Shane Peelar @ 2019-06-03  4:50 UTC (permalink / raw)
  To: Mark Hatle; +Cc: Yocto Project

[-- Attachment #1: Type: text/plain, Size: 14851 bytes --]

Will do, thanks!

On Sat, Jun 1, 2019, 3:50 PM Mark Hatle, <mark.hatle@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@windriver.com
> > <mailto:mark.hatle@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@gmail.com
> >     <mailto:raj.khem@gmail.com>
> >     > <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>> wrote:
> >     >
> >     >     On Fri, May 24, 2019 at 6:58 PM Shane Peelar
> >     <lookatyouhacker@gmail.com <mailto:lookatyouhacker@gmail.com>
> >     >     <mailto:lookatyouhacker@gmail.com <mailto:
> lookatyouhacker@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@gmail.com
> >     <mailto:raj.khem@gmail.com>
> >     >     <mailto:raj.khem@gmail.com <mailto:raj.khem@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@gmail.com
> >     <mailto:raj.khem@gmail.com>
> >     >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
> >     >     >> > <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>
> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@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@gmail.com <mailto:raj.khem@gmail.com>
> >     >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
> >     >     >> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com
> >
> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>>
> >     >     >> >      > <mailto:raj.khem@gmail.com <mailto:
> raj.khem@gmail.com>
> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
> >     >     <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>
> >     <mailto:raj.khem@gmail.com <mailto:raj.khem@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
> >     >     >> >      >      >
> >     >     >> >      >
> >     >     >> >
> >     >
> >     >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 23426 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-06-03  4:50 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-23 15:05 prelink-cross with -fno-plt Shane Peelar
2019-05-24  1:59 ` Khem Raj
2019-05-24  2:53   ` Shane Peelar
2019-05-24  4:08     ` Khem Raj
2019-05-24 15:10       ` Shane Peelar
2019-05-24 16:27         ` Khem Raj
2019-05-25  1:58           ` Shane Peelar
2019-05-25  6:30             ` Khem Raj
2019-05-25 12:53               ` Shane Peelar
2019-05-28 18:57                 ` Mark Hatle
2019-05-29 18:42                   ` Shane Peelar
2019-06-01 22:50                     ` Mark Hatle
2019-06-03  4:50                       ` Shane Peelar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.