1. Home
  2. Embedded Programming
  3. MSP430 GDB problem.

MSP430 GDB problem.

Greetings. I'm not sure this is the appropriate forum for this query but I haven't been able to find a forum dedicated to the MSP430 port of GDB. I am using msp430-gdb GNU gdb 5.1.1 Code is compiled with msp430-gcc version 3.3 debugging options are enabled. msp430-gdb works fine except that arguments to functions can't be examined. Ie when I put a breakpoint inside a function the values in the arguments display garbage - often zero. Local variables declared inside the function can be examined. The only way I can examine the arguments is by delcaring a pointer inside the function and setting it to the argument address, but this is obviously clumsy. Should I expect to be able to view the values of arguments when inside the function? Is there a setting to enable it? Am I overlooking something? Any help appreciated.

Reply to
edson
Loading thread data ...

Hmm. I haven't noticed that problem. Have you tried disabling optimization?

You might want to ask on the mspgcc mailing list.

formatting link

[...]

I would think so. I've never noticed that particular problem on the '430 or on other architectures.

--
Grant Edwards                   grante             Yow!  Where's SANDY DUNCAN?
                                  at               
                               visi.com
Reply to
Grant Edwards

You might also want to get a more recent gdb build (the mspgcc folks have ready-to-run windows builds, and a *nix build should be reasonably easy). Newer gcc versions can generate more advanced debugging information that can confuse older gdb versions, especially with heavily optimised code.

Reply to
David Brown

According to the download page at the mspgcc sourceforge site, gdb 5.1.1 is "latest". The gdb binary in the Windows download version is 6.0, but the last time I checked, there was still a lot of breakage in 6.0 (e.g. backtrace doesn't work).

I certainly haven't found that to be the case. I was unable to build MSP430 gdb versions any newer than 5.1.1, and I've been building gnu tools for cross development for many years and many platforms. Since 6.x is broken, I decided to just use

5.1.1. 

--
Grant Edwards                   grante             Yow!  HOW could a GLASS
                                  at               be YELLING??
                               visi.com
Reply to
Grant Edwards

I must admit I've not had occasion to need backtracing, so I don't know how big a problem that is. However, I note that the the windows builds on sourceforge went from gdb 6.0 back to 5.11 due to problems with single stepping, and then went back to 6.0 again. It's a while since I downloaded, so I'm not sure what the currently recommended version is.

I haven't build gdb for the msp430 for a while (I've been lazy, and downloaded pre-build binaries), so I can't really comment, other than if they've managed to build 6.0 under cygwin, a *nix build is unlikely to be harder.

The msp430 gcc mailing list is pretty active - you'll probably get much more useful answers there.

Reply to
David Brown

That's what I expected. When I was searching for hints on how to build 6.0 a few weeks ago, I found postings to the mailing list that said 6.0 backtrace didn't work yet, so I just stuck with 5.1.1

Yup, that's where I found that 6.0 still doesn't work right. That may have changed in the past few weeks, but I've been reading the list and haven't seen anythign to that effect.

--
Grant Edwards                   grante             Yow!  TAILFINS!!...click...
                                  at               
                               visi.com
Reply to
Grant Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.