Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 814248
Summary: | issue with 'NR_CPUS' definition on ARM | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> |
Component: | crash | Assignee: | Dave Anderson <anderson> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | anderson, dsmith, fche, jistone, mjw, pmuller, scox, wcohen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
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 22:38:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 245418 |
Description
Peter Robinson
2012-04-19 13:09:04 UTC
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 |