This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR4186: cross-compilation, $ARCH


On 08/25/2009 08:33 AM, Frank Ch. Eigler wrote:
> 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.

I've got a couple of thoughts here:

- Are we planning on extending '%arch' (or perhaps adding '%user_arch')
to tell the difference between 32-bit and 64-bit user exes?

- I'd probably go with solution #2, but also provide "aliases" for the
old names (assuming that's possible).

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]