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: systemtap ARM port status


On Fri, Jun 01, 2007 at 04:12:58PM -0400, Anderson Lizardo wrote:
On 6/1/07, Quentin Barnes <qbarnes@urbana.css.mot.com> wrote:
Note though that the ARM port work doesn't yet include all the
changes to get the testsuite to run on an ARM platform.  I'm still
working on those and will be submitting them to the list soon.

Nice! Have you already tested some of the example .stp scripts from the systemtap package on ARM?

No, I've been concentrating on getting the full testsuite to pass first. I've just made some changes today that I think will get virtually all the tests to pass that are expected to pass on the kernel version and configuration I'm using.

However, one of the changes I made to loc2c-runtime.h shouldn't be
necessary, if anything, it should cause things to fail, but instead
it makes some tests now pass.  I sent some mail to Martin about it
to see if he has any ideas as to what's going on.

Well, for now I'm running completely native.  Yes, that's very, very
painful to run gcc and g++ on such a board with an NFS mounted file
system and NFS mounted swap file over loopback.  It can take four
hours of wall time to compile and link the "stap" binary and the
better part of a day to run the full testsuite.

How do you solve the problem of having the kernel and the modules compiled with the same toolchain? Do you also compile the kernel on ARM?

I do cross-build the kernel for all my development.


You don't have to use the identical toolchain for both.  You just
have to configure the native and cross kernels identically, which I
do.

On my cross environment, I'm using CodeSourcery's ARM Sourcery G++
2006q3-26.  Natively I'm using Debian 4.1.1-21.

I push my devel kernel tree over to the native platform then rebuild
enough of the kernel tools to build modules.  Basically, I find
all objects that are i386 native in the "O" directory of the kernel
tree, rm them, then natively "make" to just build the necessary
pieces natively.

To back up a bit, where are you getting the ARM Kprobes port from?
Is this based on Sagar and my work I posted to the ARM Linux kernel
mailing list recently, or some other ARM Kprobes port?

We are using the patches you sent to LKML a while ago. Any changes to those patches since then?

I never posted anything to the LKML mailing list. I've only posted to Sytemtap (this list) and the ARM Kernel mailing list. You should definitely use the work from my post to the latter on May 17.

BTW, we had a couple of problems getting them to compile for OMAP and
QEMU (emulated Versatile platform):

- errors about undefined "__asm__" macros on kprobes-decode.c. To
workaround, we changed all occurrences to "asm".
- an error about undefined "__LINUX_ARM__ARCH___" (note the additional
underlines) on kprobes-decode.c. We changed it to
"__LINUX_ARM_ARCH__". Maybe it was a typo?
- we removed the "___attribute___((naked))" atributte from
kretprobe_trampoline_holder() since our compiler (CodeSourcery
2006q3-27) didn't seem to like it)

These are all very strange problems you shouldn't have had. First, we're using virtually identical compilers (CodeSourcery's 2006q3-26 vs. 2006q3-27).

The keyword "__asm__" has been in all versions of gcc I'm personally
aware of going all the way back to gcc 2.95.3.  You can find it on
the gcc.gnu.org documentation even for that version.

In the patch sets I posted to both mailing lists, the macro is
"__LINUX_ARM_ARCH__", not "__LINUX_ARM__ARCH___" or anything else.
Sounds like you have a damaged or strangely hacked patch.

The attribute "__attribute__((naked))" has been in the ARM port a
very long time, at least since gcc 3.2.3, and I'm positive it is in
2006q3-27.

Where did you get your CodeSourcery compiler from?  Are you running
the binary release, or did you build it yourself from the source
release?  Or could someone have hacked the default compiler flags in
your arch/arm/Makefile?

Sounds like you've got both a bad patch and a misconfigured GCC
compiler.

After patching these issues, we could get some simple tests from
kprobes.txt to run.

Regards,
--
Anderson Lizardo
Open Source Mobile Research Center - OSMRC
Nokia Institute of Technology - INdT
Manaus - Brazil

Quentin



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