This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: staprun-only system


Frank Ch. Eigler <fche@redhat.com> wrote:
> 
> Jim Keniston <jkenisto@us.ibm.com> forwarded:
> 
> > [...]
> > I tried the ./configure on the target system and it did not generate a
> > Makefile as the elfutils where not installed, I could install them, but
> > since staprun does not need them I wanted to simplify my target system
> > default install by not requiring extra rpms for debug. 
> 
> We could add a configure option to disable building the translator,
> and thus only build staprun/stapio.
> 
> 
> > Since make install did not work. I copied the files by hand. I am still
> > cleaning up a issue where staprun will not load the previously built
> > scsi_test systemtap module.
> > "# staprun ./scsi_test.ko
> > ERROR: scsi_test: inconsistent scsi_mod build-id byte #0 (0x6e [actual]
> > vs. 0x83 [debuginfo])"
> 
> This usually indicates a mismatch between the kernel build you've
> targeted for the instrumentation and the kernel build you're trying to
> run it on.
> 

The current running kernel and the module contain the same vermagic
string. I will spend some time on trying to locate why my build-ids
differ.


> > Here is my current process.
> >
> > #On the Build system.
> > [...]
> > #On Target system.
> > [...]
> 
> If you're already building the whole systemtap on your build machine,
> was there some reason not to just copy the staprun/stapio executables
> over to the target?

My build system is currently a Fedora release 9 system and the target
system is running SUSE Linux Enterprise Server 10. I thought the
difference in distros would lead to issues in just copying the files. I
previous had tried it during some testing and had issues.

I just tried copying the files over from build to target system. The
staprun failed to run. I assume this is because of the glibc 2.8 vs the
2.4 version on the target system.

# staprun ~/scsi_test.ko 
Floating point exception

# ldd stapio
 ./stapio: /lib64/libc.so.6: version `GLIBC_2.8' not found (required by
 ./stapio)

# readelf -s stapio | grep -i GLIBC_2.8
    33: 0000000000000000   139 FUNC    GLOBAL DEFAULT  UND __asprintf_chk@GLIBC_2.8 (6)
    173: 0000000000000000   139 FUNC    GLOBAL DEFAULT  UND __asprintf_chk@@GLIBC_2.8

 	

-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]