Setting up an open-source development environment is not that bad, although you will never get the sort of functionality you can get from a commercial IDE. I was setting up an environment for STM32 like a week ago under windoze.
You need following stuff:
-Eclipse IDE for C/C++ development (google it)
-arm-none-eabi (so called 'bare metal') gcc. There's linaro, Yagarto, CodeSourcery and few others. Every package has compiler, linker, various converters, packers, splitters etc.
-openocd. Google it. Latest stable version is 0.6.1 available from official site. For windoze binaries you can go to a website of Polish colleague
www.freddiechopin.info. He provides openocd binaries for windoze. If you aim for Stellaris Launchpad then you need 7.0.2 rc version.
-zylin embedded CDT plugin and GDH harware debug plugins for Eclipse
You can find tutorials on the net on how to put this all together. One thing you cannot typically do is looking at / editing peripheral registers. By default you only see ARM core internal registers. There is a plugin called embsysregview that overcomes that, although its support list is kinda limited.
For particular mcu you need to get following things:
-libraries and header files - obviously
-proper makefile OR compiler parameters that will inform GCC compiler that you are compiling for example for Cortex M4 and whether your controller has an FPU. This makes compiler spit out usable code
-linker script - this will tell the linker where in memory to put variables, instructions, functions pointers etc. It's vital for example for interrupt jump instructions to end up in proper memory cell. Those scripts can be downloaded or written by yourself if you're that hardcore
-startup file. A code file, usually asm, but c is also found, that sets up stack pointers and some other basic stuff
For ARM controllers I would say your best shot are either ST or NXP. ST sells stm32vldiscovery which contains stlink-v1 (swd mode only IIRC) which works with all STM32 controllers and works very well with openocd. NXP on the other hand has cheaper MCUs but those cheaper MCUs - like for example LPC1111 - do not use JTAG, only SWD. And NXPs implementation of SWD state machine doesn;t go along with generic SWD dongles. And if it does they typically don;t work with openocd. NXPs LPClink debugger has proprietary encrypted interface which NXP refused to make available to openocd developers. TI's products are on an expensive side compared to NXP and ST. I think that ST's "discovery" evaluation boards offer the best value for money. And ST makes very good silicon (especially if you know from your own experience what a mess that company is internally... )