PR4186: cross-compilation, $ARCH

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

We need to clear up our use of the generic term "architecture" in
stap, as visible to scripts %( arch %) and the build system (-a foo or
-B ARCH=foo).  The linux kernel has a less fuzzy meaning for it than
we have had, roughly as embodied by the SUBARCH computation in the
top level Makefile:

SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
                                  -e s/arm.*/arm/ -e s/sa110/arm/ \
                                  -e s/s390x/s390/ -e s/parisc64/parisc/ \
                                  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
                                  -e s/sh[234].*/sh/ )


Whereas we in stap land have used uname(2)'s machine, or approximating
"uname -i".  But neither of those matches SUBARCH/ARCH, for cases such
as s390[x], powerpc[64], and others.  The current systemtap git code
breaks on these latter ones.

So, what to do?  A few options:

- Revert some of my cross-arch code, so as to avoid passing ARCH=foo to
  the build system if the user hasn't attempted to override the default.
  This would preserve the inconsistency.  Tapsets would not exist for
  where "uname -m" gives wordy labels like "armv5tejl". 

- Add the same SUBARCH-flattening hack to systemtap, so that we think
  in terms of the same "arch" value as the kernel.  (I don't think
  there exists any kernel API or /proc filesystem that gives us this
  string back at run time!)  So "ppc64" would become plain "powerpc",
  "s390x"->"s390", "arm5tejl"->"arm", and so on.  Tapsets would have
  to be moved around a little more, and third-party scripts that use
  the old %( arch %) names would have to change.

I'm leaning for #2, but I'm looking for more alternatives or advice.

- FChE