[1/1] systemtap-uprobes: inhibit package strip

Submitted by Wade Farnsworth on Aug. 2, 2012, 2:19 p.m.

Details

Message ID 501A8C5C.8090503@mentor.com
State New
Headers show

Commit Message

Wade Farnsworth Aug. 2, 2012, 2:19 p.m.
uprobes.ko is not located in /lib/modules, so it fails the check in
runstrip that ensures that only the debug section is stripped, leaving
the symbols untouched.  This prevents the module from being inserted at
run time.  Inhibiting package stripping fixes the problem.

Signed-off-by: Wade Farnsworth <wade_farnsworth@mentor.com>
---
 .../systemtap/systemtap-uprobes_git.bb             |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb b/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
index b328e6b..f135a54 100644
--- a/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
@@ -9,6 +9,8 @@  PR = "r0"
 # On systems without CONFIG_UTRACE, this package is empty.
 ALLOW_EMPTY_${PN} = "1"
 
+INHIBIT_PACKAGE_STRIP = "1"
+
 inherit module-base gettext
 
 FILES_${PN} += "${datadir}/systemtap/runtime/uprobes"

Comments

Richard Purdie Aug. 15, 2012, 1:24 p.m.
On Thu, 2012-08-02 at 07:19 -0700, Wade Farnsworth wrote:
> uprobes.ko is not located in /lib/modules, so it fails the check in
> runstrip that ensures that only the debug section is stripped, leaving
> the symbols untouched.  This prevents the module from being inserted at
> run time.  Inhibiting package stripping fixes the problem.
> 
> Signed-off-by: Wade Farnsworth <wade_farnsworth@mentor.com>
> ---
>  .../systemtap/systemtap-uprobes_git.bb             |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb b/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
> index b328e6b..f135a54 100644
> --- a/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
> +++ b/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
> @@ -9,6 +9,8 @@ PR = "r0"
>  # On systems without CONFIG_UTRACE, this package is empty.
>  ALLOW_EMPTY_${PN} = "1"
>  
> +INHIBIT_PACKAGE_STRIP = "1"
> +
>  inherit module-base gettext
>  
>  FILES_${PN} += "${datadir}/systemtap/runtime/uprobes"

I think we need to teach package.bbclass to identify kernel modules
better (.ko extension?) rather than hack around this for each external
module...

Cheers,

Richard
Martin Jansa Aug. 15, 2012, 1:30 p.m.
On Wed, Aug 15, 2012 at 02:24:58PM +0100, Richard Purdie wrote:
> On Thu, 2012-08-02 at 07:19 -0700, Wade Farnsworth wrote:
> > uprobes.ko is not located in /lib/modules, so it fails the check in
> > runstrip that ensures that only the debug section is stripped, leaving
> > the symbols untouched.  This prevents the module from being inserted at
> > run time.  Inhibiting package stripping fixes the problem.
> > 
> > Signed-off-by: Wade Farnsworth <wade_farnsworth@mentor.com>
> > ---
> >  .../systemtap/systemtap-uprobes_git.bb             |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb b/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
> > index b328e6b..f135a54 100644
> > --- a/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
> > +++ b/meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
> > @@ -9,6 +9,8 @@ PR = "r0"
> >  # On systems without CONFIG_UTRACE, this package is empty.
> >  ALLOW_EMPTY_${PN} = "1"
> >  
> > +INHIBIT_PACKAGE_STRIP = "1"
> > +
> >  inherit module-base gettext
> >  
> >  FILES_${PN} += "${datadir}/systemtap/runtime/uprobes"
> 
> I think we need to teach package.bbclass to identify kernel modules
> better (.ko extension?) rather than hack around this for each external
> module...

and sometimes it tries to strip foo.ko which is not binary file at all
(e.g. /usr/share/emacs/23.4/etc/tutorials/TUTORIAL.ko from emacs).

http://git.openembedded.org/meta-openembedded/commit/?id=d213bfac739163eb932e31181e0bfecc84507f30

Cheers,