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.

On 2006-03-09, edson <e...@eircom.net> wrote:

> 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.

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

You might want to ask on the mspgcc mailing list.

http://sourceforge.net/mailarchive/forum.php?forum=mspgcc-users

[...]

> Should I expect to be able to view the values of arguments
> when inside the function?

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            

Grant Edwards wrote:
> On 2006-03-09, edson <e...@eircom.net> wrote:
> 
>> 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.
> 
> Hmm. I haven't noticed that problem.  Have you tried disabling
> optimization?
> 
> You might want to ask on the mspgcc mailing list.
> 
> http://sourceforge.net/mailarchive/forum.php?forum=mspgcc-users
> 
> [...]
> 
>> Should I expect to be able to view the values of arguments
>> when inside the function?
> 
> I would think so.  I've never noticed that particular problem
> on the '430 or on other architectures.
> 

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.

On 2006-03-10, David Brown <d...@westcontrol.removethisbit.com> wrote:
> Grant Edwards wrote:
>> On 2006-03-09, edson <e...@eircom.net> wrote:
>> 
>>> 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.
>> 
>> Hmm. I haven't noticed that problem.  Have you tried disabling
>> optimization?
>> 
>> You might want to ask on the mspgcc mailing list.
>> 
>> http://sourceforge.net/mailarchive/forum.php?forum=mspgcc-users
>> 
>> [...]
>> 
>>> Should I expect to be able to view the values of arguments
>>> when inside the function?
>> 
>> I would think so.  I've never noticed that particular problem
>> on the '430 or on other architectures.
>
> You might also want to get a more recent gdb build (the mspgcc
> folks have ready-to-run windows builds,

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).

> and a *nix build should be reasonably easy).

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.

> Newer gcc versions can generate more advanced debugging 
> information that can confuse older gdb versions, especially
> with heavily optimised code.

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

Grant Edwards wrote:
> On 2006-03-10, David Brown <d...@westcontrol.removethisbit.com> wrote:
>> Grant Edwards wrote:
>>> On 2006-03-09, edson <e...@eircom.net> wrote:
>>>
>>>> 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.
>>> Hmm. I haven't noticed that problem.  Have you tried disabling
>>> optimization?
>>>
>>> You might want to ask on the mspgcc mailing list.
>>>
>>> http://sourceforge.net/mailarchive/forum.php?forum=mspgcc-users
>>>
>>> [...]
>>>
>>>> Should I expect to be able to view the values of arguments
>>>> when inside the function?
>>> I would think so.  I've never noticed that particular problem
>>> on the '430 or on other architectures.
>> You might also want to get a more recent gdb build (the mspgcc
>> folks have ready-to-run windows builds,
> 
> 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 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.

>> and a *nix build should be reasonably easy).
> 
> 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.
> 

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.

>> Newer gcc versions can generate more advanced debugging 
>> information that can confuse older gdb versions, especially
>> with heavily optimised code.
> 

On 2006-03-10, David Brown <d...@westcontrol.removethisbit.com> wrote:

> 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.

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

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

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