fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
modem_ has quit [Ping timeout: 240 seconds]
hkshaw1 has joined #systemtap
hkshaw has quit [Ping timeout: 260 seconds]
hkshaw has joined #systemtap
hkshaw1 has quit [Ping timeout: 246 seconds]
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
hkshaw has quit [Quit: Leaving.]
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
srikar_away is now known as srikar
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
hchiramm has quit [Ping timeout: 260 seconds]
nkambo has joined #systemtap
hchiramm has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
srikar is now known as srikar_away
nkambo has quit [Ping timeout: 276 seconds]
srikar_away is now known as srikar
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
srikar is now known as srikar_away
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
cbzx has joined #systemtap
cbzx has quit [Quit: Konversation terminated!]
naveen has joined #systemtap
srikar_away is now known as srikar
naveen has quit [Quit: Leaving.]
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
irker002 has joined #systemtap
<irker002> systemtap: Torsten.Polle systemtap.git:refs/heads/master * release-3.0-40-g57c90ba / session.cxx: Support the sysroot option for modules added for symbol/unwind information http://tinyurl.com/zpbechs
<irker002> systemtap: Torsten.Polle systemtap.git:refs/heads/master * release-3.0-41-gdf932a3 / setupdwfl.cxx: Fix: Debug links are not found if the sysroot is used. http://tinyurl.com/hoymah2
<irker002> systemtap: Torsten.Polle systemtap.git:refs/heads/master * release-3.0-43-gc30ff77 / tapsets.cxx: Fix: process.library.function failed with sysroot. http://tinyurl.com/hdp4tne
<irker002> systemtap: Torsten.Polle systemtap.git:refs/heads/master * release-3.0-42-gc627f96 / tapsets.cxx: Fix: Processes are not found. http://tinyurl.com/j9gadz8
srikar is now known as srikar_away
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
systemtap_user has joined #systemtap
<systemtap_user> hi everyone! I'm trying to build systemtap 3.0 using my arm cross compiler. Any hints on which elfutils version I should be using? I could not find any documentation.
<fche> systemtap_user, in general, the newer the better.
<systemtap_user> fche: I see okay, thanks let me 0.164
<fche> the README says to download elfutils, so by default go for the newest yo uhave.
<fche> are you cross-building systemtap itself? or aiming to use systemtap as a cross-compiler?
hchiramm has quit [Ping timeout: 260 seconds]
<systemtap_user> id like to build stap scripts to use on my arm board -- I was on version 1.7, but it wasn't working with my newer kernel tree ; so i decided to give the newer version a try
<fche> ok; in that case you probably only need the runtime portion of systemtap built for arm (staprun -- i.e., configure --disable-translator)
<fche> and the translator portion can run on your normal (x86?) box, so doesn't need a cross elfutils
<systemtap_user> oh
<systemtap_user> i see
<systemtap_user> that is good to know
<systemtap_user> let me try that thank you fche !
<fche> righto
<fche> see the 'cross-compilation' blurbs in [man stap]
<fche> we in the the core team don't have a lot of experience with that though
* systemtap_user checks it out
<fche> if your arm box can be connected to via ssh, then stap [-a arm ...etc...] --remote=your_arm_box will work to run things under remote control
<systemtap_user> I see ; I just tried using --disable-translator but I still seem to be getting a message saying "cannot find -lelf"
<systemtap_user> Let me paste
<fche> ah yes, staprun itself uses elfutils a little bit
<systemtap_user> I see
<systemtap_user> Hmm this does not seem to occur for older versions though
<fche> yeah, very old versions no, but this should still be solvable
<fche> the --with-elfutils part here is not passed to the staprun building process apparently
<fche> so try building elfutils yourself, with a similar configure line as now, and install it whereever that gcc-cross gcc will look for it
<systemtap_user> thanks let me try that
<systemtap_user> hmm for some reason the cross compiler does not seem to be able to find that so file(though i seem to have put it along with libc.so etc), and gives me the same message. (I hope I got the lib path right on this ubuntu machine, let me recheck, I think it should be /usr/arm-linux-gnueabi/lib)
modem_ has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
<systemtap_user> i seem to have placed libelf.so in the right directory but the error seems to persist
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
<systemtap_user> ah np, i hadnt set cflags
<systemtap_user> it works now
<fche> ah good
<fche> (one additional complication with stap/elfutils is that elfutils internally loads shared libraries of its own at runtime via dlopen; can't link it statically last time I checked)
<systemtap_user> ah I see -- is that also something thats changed in the newer versions?
<fche> nope, that part's pretty old
<systemtap_user> oh okay cool
<fche> anyway if you have it working now, don't mess with it :)
<systemtap_user> haha yup :)
<systemtap_user> thanks a lot fche :)
<fche> np
<fche> so that part's the staprun build right?
<fche> do you have other parts up and running yet?
<systemtap_user> staprun and stapio, yes
<systemtap_user> i dont know, im about to try it out
<fche> aha
<fche> stapsh too would sit on the target side
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
<systemtap_user> fche: when building the stp script I seem to be getting this : https://gist.github.com/anonymous/235be0cdf988e3d43b7b06fd748ab01d -- I had this same message when using my earlier version of systemtap with a different kernel tree
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
modem_ has quit [Quit: Quitte]
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
<fche> that utils.stp file doesn't come from systemtap
<fche> wonder where you got it
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap
<systemtap_user> yeah thats a file i copied in manually -- let me try a simpler stp script to begin with
<fche> the tapset/ directory shouldn't contain anything but tapset library snippets
<fche> put your normal scripts somewhere else
irker002 has quit [Quit: transmission timeout]
<systemtap_user> fche: got it. now i seem to be getting https://gist.github.com/anonymous/e5e08d3b184acc198719500afc46b8a9
<fche> hm, what is the ./kernel directory ?
<fche> it should be an arm kernel build tree
<systemtap_user> hm, its the source tree, and i've built it once in-tree. would that do?
<fche> it should be a tree from which the arm kernel was built
<systemtap_user> yes it is
<fche> so there should be a .config file, and various such build-time-created stuff
<systemtap_user> yup there is
<fche> hm
<fche> try --vp 0004 to get some more verbosity in the build phase;
<fche> try also -r `pwd`/kernel (for full path name)
<systemtap_user> sure
<fche> um, you're running stap 1.7 still? hm
<fche> I thought you had made a 3.0 translator etc.
<fche> it's --vp 0004 not -vp 0004 btw
<fche> (those series of make -C's shouldn't be failing)
<fche> (the proper --vp ... may get us the info needed to diagnose)
<fche> but anyway should build a 3.0 native stap for your box
<fche> you don't need to do any stap -R business
<fche> ah more info there
<fche> the initial make-errors would probably explained by --vp 0404 ... or just say -vvvvv (a slew of verbosity)
<systemtap_user> I see
<fche> but what a mess in the logs
<fche> line 151 onward don't make much sense
<fche> another diagnostic tip: stap -k (keep temp dir) lets you look at those /tmp/stap*/FOO files afterwards
<systemtap_user> ah I see
<systemtap_user> thats good to know
<fche> it's as though utf-8 (?) code is getting into that generated stapconf_..._1113.h file
<fche> include/linux/types.h:107:1: error: unknown type name ‘__s8’ <-- things like that I don't quite know what to make of
<fche> the stap-generated headers / kernel module is theoretically being built with the same compiler from apprx. the same build tree as the (arm) kernel
<fche> /data/systemtap-3.0-ubuntu/share/systemtap/runtime/linux/kprobes.c:16:2: error: #error "Need CONFIG_KPROBES!" <-- and then there's that
<systemtap_user> Hmm that seems to be y in the .config
<systemtap_user> hm indeed the logs do look rather strange. let me try to see why the initial make fails with 0404.
<systemtap_user> fche: https://gist.github.com/anonymous/2c3a33bd01376444e170ee6049665734 ; i see a "ERROR: Kernel configuration is invalid."
<fche> that's just a literal printing of the contents of a makefile
<systemtap_user> ah okay
<fche> /tmp/stapH77Zcc/typequery_kmod_5/typequery_kmod_5.mod.c:8:1: error: variable ‘__this_module’ has initializer but incomplete type <-- that's weird
<fche> so these are test-builds to probe for certain kernel features
<systemtap_user> I see
<fche> so something probably localized but systemic is broken here
<fche> and I don't know what else to advise (I mean I'd go in there and start hand-building test files etc., basically reproduce what stap's trying todo ; trying to hand-build out-of-tree modules, that sort of thing)
<fche> but I can't ask you to do that sort of investigation, esp. by "remote control" :-)
<fche> is your arm target by any chance capable of self-hosting?
<fche> ie running stap locally, building its own kernel?
<systemtap_user> unfortunately nope :(
<systemtap_user> ill look into it, thanks for all the help! :)
<fche> ok. if you get stuck, please fire off a note to the mailing list with some more info, so we can try reproducing the problem here
<systemtap_user> sure thing will do
<fche> e.g. version of the target arm kernel; its .config; the origins/versions of the arm toolchain you're using
<fche> that sort of thing
<systemtap_user> right
<fche> good luck & good night :)
<systemtap_user> goodnight ! :)
systemtap_user has quit [Quit: Page closed]
Meths has quit [Read error: Connection reset by peer]
Meths has joined #systemtap