This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 814248 - issue with 'NR_CPUS' definition on ARM
issue with 'NR_CPUS' definition on ARM
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: crash (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dave Anderson
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ARMTracker
  Show dependency treegraph
 
Reported: 2012-04-19 09:09 EDT by Peter Robinson
Modified: 2012-06-10 18:38 EDT (History)
8 users (show)

See Also:
Fixed In Version: crash-6.0.6-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-10 18:38:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peter Robinson 2012-04-19 09:09:04 EDT
When we're trying to build some things against crash on ARM we get the following error (systemtap is the example):

gcc  -D_GNU_SOURCE -fexceptions -Wall -Werror -Wunused -Wformat=2 -W -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -march=armv5te -mfloat-abi=soft -fstack-protector-all -D_FORTIFY_SOURCE=2 -shared -rdynamic \
	 -Wl,-z,relro  -fPIC -o staplog.so staplog.c
In file included from staplog.c:50:0:
/usr/include/crash/defs.h:581:24: error: 'NR_CPUS' undeclared here (not in a function)
staplog.c:80:28: error: 'per_cpu' defined but not used [-Werror=unused-variable]
cc1: all warnings being treated as errors

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=742831

Build is: crash-6.0.5-1.fc18
Comment 1 Dave Anderson 2012-04-19 09:21:37 EDT
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?
Comment 2 Dave Anderson 2012-04-19 09:29:15 EDT
> 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>
Comment 3 Frank Ch. Eigler 2012-04-19 09:43:43 EDT
Thanks, we can add that, Dave.
Is there some reason that crash/defs.h doesn't itself work based on #ifdef __foo__ ?
Comment 4 Dave Anderson 2012-04-19 10:07:04 EDT
> 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.
Comment 5 Frank Ch. Eigler 2012-04-19 12:08:00 EDT
Could you support the cross-analysis case by another (non-default) macro,
and make rhel/fedora crash builds plain native?
Comment 6 Dave Anderson 2012-04-19 14:02:54 EDT
> 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 */
Comment 7 Frank Ch. Eigler 2012-04-20 15:17:27 EDT
> [...] I suppose I could add a section [...]

Yup, that would do just as well.
Comment 8 Dave Anderson 2012-04-20 15:30:48 EDT
> 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.
Comment 9 Frank Ch. Eigler 2012-04-20 16:17:52 EDT
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 ;)
Comment 10 Dave Anderson 2012-04-20 16:46:48 EDT
> 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!
Comment 11 Peter Robinson 2012-04-30 06:04:39 EDT
Any status update on this?
Comment 12 Dave Anderson 2012-04-30 08:42:01 EDT
> > 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.
Comment 13 Dave Anderson 2012-04-30 10:33:16 EDT
Information for build crash-6.0.6-1.fc18:

  http://koji.fedoraproject.org/koji/buildinfo?buildID=316178
Comment 14 Peter Robinson 2012-06-07 04:51:06 EDT
Dave, any issues with pulling 6.0.6 back into F-17?
Comment 15 Dave Anderson 2012-06-07 08:53:40 EDT
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.
Comment 16 Peter Robinson 2012-06-07 09:14:46 EDT
3.5 is in rawhide, not in F-17 so it shouldn't be a problem there. Thanks

Note You need to log in before you can comment on or make changes to this bug.