Re: My progress on armhf: xf86-video-msm for armhf attempt. Please test.
On Sat, Sep 03, 2011 at 12:26:05AM +0100, Paul Brook wrote:
> Obviously if your code assumes [say] a Cortex-A8 and uses NEON assembly
> without checking first than all bets are off. There are two ways of resolving
> this:
> - Don't do that.
> - Hack the makefile to always build with NEON enabled, and hope noone ever
> runs in on a different CPU, or tries to build for a system that is
> incompatible wth NEON.
Seems reasonable to me.
> > So is there a way to ask gcc "What the hell are your defaults right now?".
>
> I don't consider that a well formed question[1]. You should be asking what
> the compiler is *doing* right now. The answer is in a preprocessor macro.
How about "What is the default target of this gcc"? I guess that would
be gcc -dumpmachine, which gives some triplet identifying the target.
Doesn't tell you the default cpu variant being targeted, but its a start.
> Interesting options should result in some form of preprocessor macro being
> defined, so code that cares can test and act accordingly. It's possible some
> of these are missing, though in some cases the options aren't something you
> have any business wanting to know - on EABI toolchains this includes
> interworking[2]. For old-abi toolchains interworking is a valid question, but
> noone cares about those any more. There is a __THUMB_INTERWORK__ macro,
> however it almost certainly doesn't mean what you want it to (specifically it
> means you're on armv4t, so have to jump through additional hoops to make
> interworking happen). I'm not aware of any comprehensive list of these
> macros, and they vary between architectures (e.g. arm and mips both support
> big/little endian, but define different macros for it).
>
> If you mean "what options do I give to a random compiler to get the same
> output", then no you can't. There's a whole raft of twisty settings which
> effect how gcc behaves. Some are intended for the user[3], some almost
> certainly break if the user does change them, some are determined when you
> configure the compiler, some require hacking the compiler sources, and some
> combine all the above.
>
> Part of the reson for this is that GCC has way to many commandline options.
> This isn't unique to gcc, but GCC makes the mistake of putting them in the
> documentation. Some other compilers don't admit they exist until you buy an
> expensive technical support contract and ask very nicely.
>
> The other reason is that the compiler is not really a standalone utility. In
> practice you need the whole toolchain (compiler, linker and runtime libraries)
> to come as a set, correctly configured for your target. In theorysome level
> of separation is possible - the EABI isolates the compiler from the runtime
> library implementation. However everything else is explicitly expected to
> work as an intertwined set. This includes the gcc exectable when acting as a
> proxy for the linker.
>
> The uClinux folks originally tried to use other (linux or bare metal
> toolchains). However this ended up horribly fragile, and causes endless
> grief, especialy when you start caring about things like shared libraries.
Yeah I have built a tool chain for uclinux. That's an intersting task.
> The linux kernel itself also does this (uses a linux toolchain to compile
> something which isn't a linux application). However they also jump through a
> good number of hoops to make it work, and have precicely one
> application/toolchain combination they care about.
>
> Paul
>
> [1] I can't mentally reconcile "default" and "right now". In practice default
> usually means "What happens when I do X". In which case just do X and stop
> making me guess!
> [2] The EABI says interworking must always be supported. Attempting to turn
> it off means you're doing something naughty, and we get to point and laugh
> when it breaks.
> [3] user == person/script building the application.
I think I will just try not to pay attension to gcc's settings and
just try to fix more broken packages. If I see things with hard coded
settings in Makefiles, I will get rid of them and just let the toolchain
--
Len Sorensen
do its thing.
Reply to: