Red Hat Bugzilla – Full Text Bug Listing
|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>|
|Version:||rawhide||CC:||anderson, dsmith, fche, jistone, mark, pmuller, scox, wcohen|
|Fixed In Version:||crash-6.0.6-1.fc18||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-06-10 18:38:44 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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