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: error to run systemtap in an ARM platform


Hi,

In fact there was a more detailed mail on testsuite on the 1st of April 2011 where I did not get answer (maybe people throught it was a joke due to the date ;-) ). That is fairly understandable so I was about to follow-up but I moved from Linaro to unexpectingly long customer assignment and team was also too busy to help

The goal we have now is to move to v1.5 and clean all that (already tested fine by some other guy in the team). As Franck suggested, issues shall be transcribed to bugzilla and we can take care of that.

And I also still have to follow-up on remarks about power management related topics but that's another story !

Regards
Fred

Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement



>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----

> From: William Cohen [mailto:wcohen@redhat.com]
> Sent: Monday, July 18, 2011 4:12 PM
> To: Turgis, Frederic
> Cc: Da Zheng; systemtap@sourceware.org
> Subject: Re: error to run systemtap in an ARM platform
>
> On 07/15/2011 08:22 PM, Turgis, Frederic wrote:
> > Hi,
> >
> > We are making quite good use of systemtap here at TI and
> try to expand
> > to more teams internally. We use it both through cross and native
> > compilation. We have leveraged mostly v1.3 but we are
> planning to move
> > to v1.5
> >
> > - for your "probe syscalls.*" issue, I can tell it was
> working with v1.3 (we use sometimes syscalls_by_pid.stp
> example) with some instability at execution in few cases.
> Since then, sycalls.stp and syscalls2.stp have evolved and
> contain some architecture specific code. If you can't port it
> (which shall be the way to go), you can try to revert the
> commits. OK, not clean but a way to move forward if you
> really need this.
> >
> > - http://sourceware.org/systemtap/wiki/SystemtapOnFedoraArm
> mentions
> > http://omappedia.org/wiki/Systemtap, which corresponds to our
> > experiments on Android, i.e. cross-compilation. Still
> fedora page is
> > very complet and probably suits you best, use OMAP page as a
> > complement
> >
> > - https://wiki.linaro.org/Platform/DevPlatform/systemtap is also
> > interesting in its short intro to systemtap and what we require in
> > terms of debug symbols, kernel config... in context of Linaro (i.e.
> > ARM). Some thoughts also about timestamping events and a list of
> > issues discovered when running testsuite on v1.3 (you can see it in
> > mail archive, look for my e-mail)
> >
> > We don't have a huge community yet on ARM but most of the
> people whom
> > we show the tool (even customers) recognize the benefits of it and
> > somehow leverage it
> >
> > Regards
> > Fred
> >
> > Frederic Turgis
> > OMAP Platform Business Unit - OMAP System Engineering - Platform
> > Enablement
> >
> >
>
> Hi Turgis,
>
> Thanks for the SystemTap page on
> http://omappedia.org/wiki/Systemtap it was very good starting
> point for me. I wasn't aware of
> https://wiki.linaro.org/Platform/DevPlatform/systemtap.
>
> Both http://omappedia.org/wiki/Systemtap and
> https://wiki.linaro.org/Platform/DevPlatform/systemtap
> mention high resolution timers being something missing. For
> some of the issues listed on the pages it would good idea to
> put feature requests to see if some of these could be
> addressed for arm.
>
> -Will
>


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