Problem with watching c++ class member variables

Go To Last Post
41 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have recently started using c++ on an atmega16. with care it is quite efficient and I enjoy the benefits of oo coding.

but.....

I have a problem watching class member variables.

occasionally when I watch a class instance I can click in the "+" and see the members. Mostly when I click on the "+" the "+" just disappears and the watched instance is not expanded. In either case the correct ram address for the instance is shown.

I have scoured the faq/forums/net and found some discussions but no conclusion of solution on this issue. :x

Now that atmel is claiming c++ support in avrstudio I presume there is a way to do what I am trying to do.

Can anyone assist?

thanks
Greg

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just out of interest are you using namespaces? In the real VS ( not noticed in AS6) if I have a var bar in namespace foo then if I hover the cursor over bar and add it as a watch it cannot be evaluated but if I edit the watch and change it to foo::bar the it works. I guess the same could affect classes too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am not using namespaces. I am a bit of a c++ novice.

AS6 can find the class instance.... it is just when I try to expand it that it realizes it doesn't knwo what to do. :cry:

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Screenshots?

Are there any messages in the output box?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As always: Supply a minimal project that demonstrates the problem and attach it (e.g. ZIPped up) to a post here.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

argh.... my simple example works fine.

I am using templates in my actual application. maybe this contributes. I will need to investigate some more.

Greg

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Snide remark: Most bug and fault seeking involves reducing the problem space and see when the problem goes away (or starting minimal, building up and seeing when it occurs).

The hypothesis that it is templates that causes the trouble seems reasonable to me. Perhaps Studio is not to be blamed here - it might be a case of (avr-)gcc not emitting correct debugging info for instantiated templates, but this is just my private wild speculation.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Grumble, grumble.

my "simple" example has now been expanded to include template classes and also a class inheriting a template class and all works well.

has anyone else had problems similar to the one I originally described?

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One idea - Look for different types instatiations/allocations:

E.g. is it working when it is a global (i.e. statially allocated) variable and not working when it is a local (i.e. automatically allocated) variable?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

problem solved.....

the debugger was doing exactly what it should.

I had a class2 that inherited from a class1. I expected the debugger to display the members of the inherited class.

methods in class2 can access the public methods in class1.... but the debugger does not show the class1 public members.

personally I would like the class1 public members to be visible in the debugger but I can understand the argument that they should not be.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
personally I would like the class1 public members to be visible in the debugger

Me too.
Quote:
but I can understand the argument that they should not be.

I can't. What argument would that be?

Also: Taking public/protected/private into account here is wrong. In the debugger you should of-course be allowed to see non-public members also. (Think of it as all classes, in all programs, in all computers, in the whole world, is declaring the debugger a "friend" :D)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

While I don't really understand what I'm doing (as the following probably demonstrates!) I wrote this in generic VS2008 (no reason to doubt that it's really much different to VS2010). Then I tried (virtually) the same code in AS6. Watch windows attached...

#include "stdafx.h"

class foo {
public:
	foo(void);
	int inspect();
	void set(int n);
	int m_member;
};

class bar : public foo {
public:
	bar(void);
	int anotherlook();
	int m_var2;
};

foo::foo(void) {
	m_member = 456;
}

int foo::inspect() {
	return m_member;
}

void foo::set(int n) {
	m_member = n;
}

bar::bar(void) : m_var2(666) {
}

int bar::anotherlook() {
	return m_var2;
}

int _tmain(int argc, _TCHAR* argv[])
{
	int n;
	bar mybar;
	mybar.set(123);
	n = mybar.anotherlook();
}

VS2008 shows the foo and it's member from which bar is derived. AS6 does not. So this looks like a VSxxxx feature that's been lost in AS6. Presumably this bit is written by Atmel not M$?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

interestingly even if the specialisation (Class2) of the base class (Class1 - right terminology?) declares class2 as a friend the debugger does not show the public members of the base class....

from the previous post is seems as though this is probably a bug.

Do we have any way of finding out from atmel if there is a config option or work around?

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Do we have any way of finding out from atmel if there is a config option or work around?

Hmh, I guess :D

Have anyone tried to vary the optimization/debug info in the project settings? Trying to use -O0 and -g3 should add more debug information. I don't currently have a working compiler on my machine (bloody burning monkeys) to test this...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't fit my code into the device at -O0 and interestingly the code gets "lost" somewhere at -O1!!

using -g3 made no difference.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll add an improvement request with the toolchain team about this. Personally, I do not have enough knowledge about the specific implementation to say much constructive about variable visibility during inheritance

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried the test code above with -O0/-g3 and it made no difference to the watch.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll update the thread when I hear back from the toolchain guys

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.

is this feedback something that normally happens in a few days or a much longer time frame?

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wouldn't expect it to be extremely quick, but if it takes to long then you should try to nag me a bit, and I'll so how things are coming along (I'm going on vacation next week, so response time may drop a bit)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
I wouldn't expect it to be extremely quick, but if it takes to long then you should try to nag me a bit, and I'll so how things are coming along (I'm going on vacation next week, so response time may drop a bit)

The bug is accepted by the team, so now it is out of my hands :D

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am afraid some C++ debugging support, including inspecting base classes in the watch view, still is on the TODO list, see
http://support.atmel.no/bin/cust...

Support for watching base class members is backlog issue TSD-265 .

Regards,
Dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

have a good holiday.

it is the middle of winter in Sydney and the temperature is only around 20C.... I hope that it is warmer where you are:-)

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregd99 wrote:
have a good holiday.

it is the middle of winter in Sydney and the temperature is only around 20C.... I hope that it is warmer where you are:-)

Summer in Norway would be quite luxurious with those temperatures... http://www.yr.no/place/Norway/S%...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Morten,
is it too early to nag you?

it would be GREAT if we could view class members form inherited classes. :D

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

never to early, as long as I don't have to respond. I totally agree, but I would not bet money on it being in a working state anytime soon...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To say that Atmel Studio supports C++ is an overstatement (with respect to debugging).

No unified effort has ever been made to add C++ support to the DWARF parser we use in Atmel studio.

The technical reason why base members are not visible is because the parser does not traverse the inheritance hierarchies in the debug information.

AFAICS, the debug information produced by avr-gcc looks good.

Torleif

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

and a bit more info on this or related problems....

The debug gets confused with static members of classes.

for example

class aClass
{
    static int a;
    int b;
}

aClass C;

void main(void)
{
    aClass::a = 99;
    c.b = 100;
};

Here the debugger will let you watch C but C.a and C.b both have the same address and show the value of b.

The code actually works and aClass::a is stored at a different location to the non-static member(s) of C.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

and apologies in advance for the c.b syntax error. this should be C.b....

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I checked the new 6.1 beta and.... the problem with watching members of inherited classes still exists. very disappointing.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code going into the final release has the following fixes:

- allow watching base class members and fix for the offset error with static data members
- fix for interrupt flag corruption when stepping simulator and avr8 devices
- workaround for debug info issues with GCC on SAM4L
- post-verify for incremental modes
- better progress report during launch

If anyone is willing to test these changes let me know and I will send you an (unofficial) patch.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If anyone is willing to test these changes let me know and I will send you an (unofficial) patch.

Happily.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

me too!

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am attaching a link to a zip of a snapshot of the Atmel Studio backend with the promised fixes (and probably a whole new load of bugs). To install, just rename your old 6.1 beta atbackend directory and unzip the archive in the Studio directory.

Please test and report any failures in watching C++ objects. Thanks for taking time to testing this, much appreciated.

Dan

[edit] New snapshot now, without bogus "Verify error"

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After installing the new backend and rebuilding.... attempting to watch debugQ debug gives the following error

Quote:
debug {class debugQ{data}@0x00a9} class debugQ{data}@0x00a9
class_Q Syntax error: parsing stopped at >. Error

class baseQ
{
	public:
		byte size;
		byte inp;
		byte outp;
		byte max;
		//const tQCB * qcb;
			
		baseQ(void){};
		//void init(const tQCB * _qcb);
		bool empty(void);
		void reset(byte resetType);
		void incIn(byte qSize);
		void incOut(byte qSize);
		void clear(void);
};

template  class Q : public baseQ
{
	private:
		friend class LogQ;
	public:
		qType buf[qSize];

		Q(void){};
		void put(qType data);
		qType get(void);
};

class debugQ : public Q //, RST_NORESET>
{
	private:
	public:
		debugQ(void){};
		void putstrP(const char *str);
		void putstrP(const char* str, unsigned int x);
		void putstrP(unsigned int x, unsigned int base);
		void putstrP(const char* str, unsigned int x, unsigned char base);

		void putstr(const char *str);
		//void putstr(const char* str, unsigned int x);
		void putstr(unsigned int x);
		void putstr(unsigned int x, unsigned int base);
		//void putstr(const char* str, unsigned int x, unsigned char base);	
};

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but then it is possible to watch the following timer class.

class timerBase
///
/// a definition for doxygen??
///
///
{
	public:
		byte prescale;
		byte size;
		byte max;
		
		timerBase(void){};
		void tick(t_timer * timer, tSignal signal);
		t_timer * get(t_timer * timer, byte qSize, byte resetType);
		void stop(t_timer * timer,  byte pid);
};

template  class Timer : public timerBase
{
	private:

	public:
		volatile byte busy;
		
		t_timer buf[qSize];
		
		Timer(void)
		{
			prescale = _prescale;
		};
		
		bool tick(void);
		void start(byte ticks, byte pid);
		void stop(byte pid);
};

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've updated the snapshot to a version that allows watching templated base classes as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Watching classes with templated base classes now seems to work fine! Thanks.

I have not understood the pattern quite yet but there seems to be a separate issue where global classes are sometimes shown as "optimised away"even though they are not.

in my main routine I call debug.putstr("string") but debug is reported as optimised away in the watch window. the code works fine and if I step into putstr() then I can watch the class debug.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
in my main routine I call debug.putstr("string") but debug is reported as optimised away in the watch window. the code works fine and if I step into putstr() then I can watch the class debug.

any feedback on this issue?

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Greg

I'm afraid there's not much I can do here, since the compiler doesn't tell us where the "debug" variable is located in memory. Here's debug info in the ELF file related to the debug variable:

 <3><609>: Abbrev Number: 49 (DW_TAG_variable)
    <60a>   DW_AT_name        : debug	
    <60e>   DW_AT_decl_file   : 1	
    <60f>   DW_AT_decl_line   : 74	
    <610>   DW_AT_type        : <0x1b0>

Usually we'd get an DW_AT_location attribute that would tell us where the object is located, but this is missing in this case. I will pass this on to the toolchain team (bugnr AVRTC-664) for an explanation or (better) a fix.

When stepping into a member function, "this" is properly described and as such you can watch the object.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for having a look at the issue and raising a ticket.

regards
Greg