Bug 814248

The defs.h file has these NR_CPUS definitions near the top
of the file:

#ifdef X86
#define NR_CPUS  (256)
#endif
#ifdef X86_64
#define NR_CPUS  (4096)
#endif
#ifdef ALPHA
#define NR_CPUS  (64)
#endif
#ifdef PPC
#define NR_CPUS  (32)
#endif
#ifdef IA64
#define NR_CPUS  (4096)
#endif
#ifdef PPC64
#define NR_CPUS  (1024)
#endif
#ifdef S390
#define NR_CPUS  (64)
#endif
#ifdef S390X
#define NR_CPUS  (64)
#endif
#ifdef ARM
#define NR_CPUS  (4)
#endif

So in order to compile with it, the user has to do their
own architecture-specific #define before #include'ing defs.h.

Is there somewhere in the systemtap sources that sets the
appropriate architecture?

> Is there somewhere in the systemtap sources that sets the
> appropriate architecture?

Here's the relevant part of staplog.c that needs ARM support:

/* crash/defs.h defines NR_CPUS based upon architecture macros
   X86, X86_64, etc.  See crash/configure.c (!). */
#ifdef __alpha__
#define ALPHA
#endif
#ifdef __i386__
#define X86
#endif
#ifdef __powerpc__
#define PPC
#endif
#ifdef __ia64__
#define IA64
#endif
#ifdef __s390__
#define S390
#endif
#ifdef __s390x__
#define S390X
#endif
#ifdef __powerpc64__
#define PPC64
#endif
#ifdef __x86_64__
#define X86_64
#endif

#include <crash/defs.h>

Thanks, we can add that, Dave.
Is there some reason that crash/defs.h doesn't itself work based on #ifdef __foo__ ?

> Is there some reason that crash/defs.h doesn't itself work based on #ifdef
> __foo__ ?

Well -- especially in the case of ARM -- yes.

Those #defines above are used by the crash utility in order to select
the correct machine-specific source file to build into the crash binary.
(i.e., there's an x86.c, x86_64.c, ppc64.c, etc. file that gets built
and linked-in with the machine-independent parts.)

So anyway, the crash utility is built natively as an ARM binary, but because
it's may be inconvenient to analyze a vmcore on an actual ARM host (often
embedded), crash can also be built as an x86 or x86_64 binary to run on an
x86/x86_64 host, but with the "ARM" #define above turned on so that the correct
machine-specific "arm.c" source file gets built into the crash utility.

The same thing applies, say, if you want to build an x86_64 binary
to analyze x86 vmcores, or if you want to build a ppc64 binary to analyze
ppc vmcores.  Those particular binaries are not part of any RHEL/Fedora 
crash package, but they can be built from the source package if the user
desires to do so.

Could you support the cross-analysis case by another (non-default) macro,
and make rhel/fedora crash builds plain native?

> Could you support the cross-analysis case by another (non-default) macro,
> and make rhel/fedora crash builds plain native?

I'd prefer not to...  

But on the other hand, since this issue is solely restricted to
handling the NR_CPUS #define, I suppose I could add a section 
to defs.h after this part:

 #ifdef X86
 #define NR_CPUS  (256)
 #endif
 #ifdef X86_64
 #define NR_CPUS  (4096)
 #endif

 ... [ cut ] ...

 #ifdef ARM
 #define NR_CPUS  (4)
 #endif

that does something like this:

 /*
  * For those users who don't define their arch with one of the above.
  */
 #ifndef NR_CPUS
 
 #ifdef __i386__
 #define NR_CPUS  (256)
 #endif
 #ifdef __x86_64__
 #define NR_CPUS  (4096)
 #endif

 ... [ cut ] ...

 #ifdef __arm__
 #define NR_CPUS  (4)
 #endif
 
 #endif   /* ifndef NR_CPUS */

> [...] I suppose I could add a section [...]

Yup, that would do just as well.

> Yup, that would do just as well.

Actually that may not solve the problem, because it's also possible 
that staplog (or other extension module that doesn't define an ARCH) 
may need some of the other machine-specific information that is within
the "#ifdef ARCH" sections of defs.h.

So here's what I'm going in the next crash release:

--- defs.h      20 Apr 2012 14:35:36 -0000      1.515
+++ defs.h      20 Apr 2012 15:18:11 -0000
@@ -65,6 +65,38 @@
 #  define offsetof(TYPE, MEMBER) ((ulong)&((TYPE *)0)->MEMBER)
 #endif
 
+#if !defined(X86) && !defined(X86_64) && !defined(ALPHA) && !defined(PPC) && \
+    !defined(IA64) && !defined(PPC64) && !defined(S390) && !defined(S390X) && \
+    !defined(ARM)
+#ifdef __alpha__
+#define ALPHA;
+#endif
+#ifdef __i386__
+#define X86
+#endif
+#ifdef __powerpc__
+#define PPC
+#endif
+#ifdef __ia64__
+#define IA64
+#endif
+#ifdef __s390__
+#define S390
+#endif
+#ifdef __s390x__
+#define S390X
+#endif
+#ifdef __powerpc64__
+#define PPC64
+#endif
+#ifdef __x86_64__
+#define X86_64
+#endif
+#ifdef __arm__
+#define ARM
+#endif
+#endif
+
 #ifdef X86
 #define NR_CPUS  (256)
 #endif

Frank, are you going to add ARM to staplog.c for the sake of
consistency?  If not, you can go ahead and change the component
back to crash.

git systemtap already has the ARM define in it; just not sure how soon we will release (or pre-release respin rawhide).  Your choice whether you want to keep this BZ for stap until that respin, or take it back for crash.

(For ALPHA, drop the ;)

> git systemtap already has the ARM define in it; just not sure how soon we will
> release (or pre-release respin rawhide).  Your choice whether you want to keep
> this BZ for stap until that respin, or take it back for crash

OK, if I get it into to rawhide first, I'll take it back...

> (For ALPHA, drop the ;)

Oops -- thanks!

Any status update on this?

> > git systemtap already has the ARM define in it; just not sure how soon we will
> > release (or pre-release respin rawhide).  Your choice whether you want to keep
> > this BZ for stap until that respin, or take it back for crash.

> > OK, if I get it into to rawhide first, I'll take it back...

I did an upstream crash utility release last Friday.  I'll rebase Fedora rawhide
sometime later today.

Information for build crash-6.0.6-1.fc18:

  http://koji.fedoraproject.org/koji/buildinfo?buildID=316178

Dave, any issues with pulling 6.0.6 back into F-17?

I suppose not, other than the fact that crash will currently not work
at all with 3.5-based kernels due to the recent upstream printk/log_buf 
changes.

3.5 is in rawhide, not in F-17 so it shouldn't be a problem there. Thanks