This information was current as of 2015-05-08: My versions of software:

MSP430-GCC  3_02_03_00
Linux version 3.4-9-rtai-686-pae (Debian 3.4.55-4linuxcnc) (this is an i386 distribution)
GNU DDD 3.3.12

I have spent years programming the MSP430 in a professional setting where I had great tools.  I am no longer in that role, so I have needed to learn how the free tools work with the MSP430.  I would like to give a big THANK YOU to TI for supporting msp-gcc.  Even though TI has stepped up to the plate, there is a lot of old information floating around on the web and significant confusion on how to use the tools.  I am a newbie to the use of gdb. It looks like it would have made my life MUCH better in college had I known about it.  I would like to post what I have learned about it so that other's may suffer less than I had to.  Since I am eyeball deep in my Shizuoka mill conversion to linuxcnc, the host I am using for this work is built on the i386 based linuxcnc box.

I got a HUGE BENEFIT from following the instructions at

With those instructions I built msp430-gcc.  I do not remember having to go retrieve anything special to build it.  I DID need to wait until it was done to install the header files where they needed to be, because the directories for them are created by using make install from the msp430-gcc source code.

I did need to install mspdebug 
apt-get install mspdebug

I made the mistake of trying to use the generic gdb that comes from the ubuntu distribution to try to talk to mspdebug.  When I would try to use gdb I would get the error 

Reply contains invalid hex digit 59

Solution?  Use msp430-gdb instead.  

What does typical workflow look like?  I am writing a program called cl.c.

[In one terminal window]
# You can use any editor you want, but I was forced to learn vi forever ago, and I kinda like it...kinda...
vi cl.c

# FOR THE LOVE OF ALL THAT IS HOLY DO NOT SKIP THE -gdwarf-2 and -g3 options!!!
# They pass on the information needed to view local variables.  I had started to give up on gcc
# until I found by D.J. Delorie! 

# Compile your
/opt/msp430-toolchain/bin/msp430-gcc -mmcu=msp430g2553 -O0 -ggdb -Wa,-ahldn -gdwarf-2 -g3 cl.c
# -mmcu obviously sets the chip you are compiling for
# -O0 removes all code optimization -- Keeps the compiler from unlooping your code, inlining stuff, and other
# optimizations that make the debugger crazy(er)
# -ggdb include gdb debugging symbol information VERY IMPORTANT
# -Wa,-ahldn produces a memory map with the assembly.  Can be pretty handy
# -gdwarf-2 includes more symbol information for gdb VERY IMPORTANT
# -g3 includes more symbol information for gdb VERY IMPORTANT
# cl.c

mspdebug rf2500
(mspdebug) prog a.out
(mspdebug) gdb
Bound to port 2000. Now waiting for connection...

[In another terminal window]

(gdb) target remote localhost:2000
(gdb) file a.out
(gdb) continue

Press Ctrl-C to stop execution.
'n' steps one line of C code at a time.
'stepi' will step one assembly instruction at a time.

I learned that
msp430-gdb -w
will bring up the graphical interface (insight) and will actually connect to the target.  Trying to do it by just starting insight didn't work for me.
I am still evaluating the use of insight.  I think I like ddd better.

USING DDD as your Debugger GUI
apt-get install ddd
apt-get install gnuplot
ddd --debugger /opt/msp430-toolchain/bin/msp430-gdb --gdb
#--debugger /opt/msp430-toolchain/bin/msp430-gdb tells ddd to use msp430-gdb instead of regulat gdb
#--gdb tells ddd to use gdb style commands to talk to the debugger.
When ddd starts up, one still needs to go the (gdb) command window within ddd and type
target remote :2000
This assumes you are on the default port and the localhost.

Thus far, I have been pretty impressed with ddd.  It has most of the stuff I would expect to be able to see. I am still struggling to figure out how to display the SFR's.  For example, right now I add a display for P10UT as
That works, bur does not format it in a pretty way, nor does it label it, nor can I pick it from a list.

Programming, Erasing, and other stuff without restarting gdb
From within GDB, it is possible to pass commands to mspdebug that it should execute.  The one for programming the chip is very handy.  These are all issued in gdb, not within mspdebug.  In DDD, the gdb console is where you type these.

monitor reset
monitor erase
monitor prog cl.c
#monitor tells gdb

Keeping msp430-gdb listening
With the monitor commands, I don't think it is necessary to keep going back to mspdebug and typing gdb.  To keep mspdebug from exiting back to command mode, one can set the option gdb_loop. 
opt gdb_loop true

for some reason, when I plugged in my MSP-FET430UIF JTAG adapter to try it out instead of the cute little launchpad, I got an error about not being able to locate the firmware (ti_3410.fw). 

This is the guy I am trying to use:

I got a bootleg copy of the firmware from here:

After downloading it, I copied it to my /lib/firmware directory as root
sudo cp ~/Downloads/ti_3410.fw /lib/firmware

I used to have this error:
usb 6-2: ti_download_firmware - firmware not found

Now I get this affirmation that I have done the right thing:
usb 6-2: device firmware changed


mspdebug -j uif -d /dev/ttyUSB0

Workflow for working with the MSP430F1611 and MSP430-GCC now looks like this:
I created a file call f1611.c

#This is for the olimex MSP430-P1611 board to blink the led slowly
#include <msp430.h>
int main(void)
  int a=0;
  WDTCTL = WDTPW + WDTHOLD;                 // Stop watchdog
  P6DIR = 0x01;                             // P1.0 as output
  while(1) {
    P6OUT = 0x01 & a>>15;

Then I compiled with:
/opt/msp430-toolchain/bin/msp430-gcc -mmcu=msp430f1611 -O0 -ggdb -Wa,-ahldn -gdwarf-2 -g3 f1611.c
then I loaded it onto the chip with:
mspdebug -j uif -d /dev/ttyUSB0
(mspdebug) prog a.out
I ran it with:
(mspdebug) run
Ctrl-C interrupts it.
(mspdebug) opt gdb_loop true

in a terminal window:
ddd --debugger /opt/msp430-toolchain/bin/msp430-gdb --gdb
then at the (gdb) console prompt
(gdb) target remote :2000

How to Display Special Function Register Values without looking up every single one
It appears that the SFR's ARE all in there, and all that is required to access them is to add an underscore
 to the END of the SFR name and then add a * to the beginning of it to dereference the pointer to see what the value is.  Not as easy as just a right click, but not as painful as looking them up one at a time.
display *P1OUT_

Hit Counter

sudo cp ~/Downloads/ti_3410.fw