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. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110903013313.gz15...@caffeine.csclub.uwaterloo.ca
