Debug data structures using aligned storage
Hi, I've googled for web pages and groups, but I didn't even find anyone *asking* that question: How can I debug data structures using aligned storage? It's very practical to use a graphical debugger like DDD to browse data structures like linked lists or trees. But aligned storages, as used by boost::variant, are opaque to the debugger. Blindly, Nowhere man -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
Pierre THIERRY <nowhere.man@levallois.eu.org> writes:
Hi,
I've googled for web pages and groups, but I didn't even find anyone *asking* that question:
How can I debug data structures using aligned storage?
It's very practical to use a graphical debugger like DDD to browse data structures like linked lists or trees. But aligned storages, as used by boost::variant, are opaque to the debugger.
Usually, in the debugger, you cast the base address of the actual storage to a pointer to the type stored, and go from there. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Le Sat, 17 Jun 2006 18:53:19 -0400, David Abrahams a écrit :
Usually, in the debugger, you cast the base address of the actual storage to a pointer to the type stored, and go from there.
Thanks a lot, it did the trick! In fact, I immediately ran into problems about namespaces, but I managed to find in recent gdb newsgroups postings how to do... So now I can debug my varaints! Maybe that could be valuable if such an information was in the Boost documentation? Gratefully, Nowhere man -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
Le Sat, 17 Jun 2006 18:53:19 -0400, David Abrahams a écrit :
Usually, in the debugger, you cast the base address of the actual storage to a pointer to the type stored, and go from there.
Thanks a lot, it did the trick! In fact, I immediately ran into problems about namespaces, but I managed to find in recent gdb newsgroups postings how to do...
So now I can debug my varaints! Maybe that could be valuable if such an information was in the Boost documentation?
What Dave suggested is standard information for anyone using a debugger in C++. Putting that in the Boost documentation is unnecessary.
Le Sun, 18 Jun 2006 05:31:53 -0400, Edward Diener a écrit :
What Dave suggested is standard information for anyone using a debugger in C++. Putting that in the Boost documentation is unnecessary.
Without using aligned storage, I do not see why anyone would have to do such a cast to debug data structures... So it doesn't seem to me to be standard in any way for C++. If I write, say, a linked list, I just ask my debugger to show me what object a pointer in my link object points to. As it is clear in the debug symbols that it is also a link, I see all it's members. And so on, and I can browse the contents of my list without casting any base address of anything. With aligned storage, that type information seems to be unavailable, at least in a trivial way, for the debugger, thus the cast. Are there so many cases where one uses aligned storage or a similar facility that this kind of debug-time cast is really common? BTW, is there any way for the debugger to know automatically what the type the storage should be cast to? Curiously, Nowhere man -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
Pierre THIERRY <nowhere.man@levallois.eu.org> writes:
Le Sun, 18 Jun 2006 05:31:53 -0400, Edward Diener a écrit :
What Dave suggested is standard information for anyone using a
debugger in C++. Putting that in the Boost documentation is
unnecessary.
Without using aligned storage, I do not see why anyone would have to
do such a cast to debug data structures... So it doesn't seem to me
to be standard in any way for C++.
I assume unions have the same problem. So does shared_ptr<void>. And void*. All that said, I'm sympathetic to your point of view.
BTW, is there any way for the debugger to know automatically what the
type the storage should be cast to?
Not without some extra-linguistic mechanism to tell it what type is stored. It would have to use some sort of debugger-specific hook. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Edward Diener <eddielee@tropicsoft.com> writes:
Pierre THIERRY wrote:
Le Sat, 17 Jun 2006 18:53:19 -0400, David Abrahams a écrit :
Usually, in the debugger, you cast the base address of the actual
storage to a pointer to the type stored, and go from there.
Thanks a lot, it did the trick! In fact, I immediately ran into problems
about namespaces, but I managed to find in recent gdb newsgroups
postings how to do...
So now I can debug my varaints! Maybe that could be valuable if such an
information was in the Boost documentation?
What Dave suggested is standard information for anyone using a debugger
in C++. Putting that in the Boost documentation is unnecessary.
I disagree. Certainly Pierre's experience belies that statement. More generally, variant presents a high-level abstraction, and users aren't necessarily expected to have any idea how it works internally. For the most part, a naive user with a good debugger can explore his program's data structures at will, but unlike almost any other library component, variant is a barrier to the type information the debugger needs. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Edward Diener <eddielee@tropicsoft.com> writes:
Pierre THIERRY wrote:
Le Sat, 17 Jun 2006 18:53:19 -0400, David Abrahams a écrit :
Usually, in the debugger, you cast the base address of the actual
storage to a pointer to the type stored, and go from there.
Thanks a lot, it did the trick! In fact, I immediately ran into problems
about namespaces, but I managed to find in recent gdb newsgroups
postings how to do...
So now I can debug my varaints! Maybe that could be valuable if such an
information was in the Boost documentation?
What Dave suggested is standard information for anyone using a debugger
in C++. Putting that in the Boost documentation is unnecessary.
I disagree. Certainly Pierre's experience belies that statement.
More generally, variant presents a high-level abstraction, and users
aren't necessarily expected to have any idea how it works internally.
For the most part, a naive user with a good debugger can explore his
program's data structures at will, but unlike almost any other library
component, variant is a barrier to the type information the debugger
needs.
Variant isn't the only data structure where the actual type stored is not known at compile time and therefore unavailable to the debugger to show to the user. You yourself pointed out the others. Every good programmer of which I know is cognizant of the technique of casting the variable or memory area, from within a debugger, to the actual type so that the debugger shows the value. Are you saying it should be up to Boost to tell the programmer about this technique ? I am not saying it might not be helpful, but I do not think it belongs in the documentation as a general rule since the technique is universal to other similar situations, and not to just one or two Boost libraries.
Variant isn't the only data structure where the actual type stored is not known at compile time and therefore unavailable to the debugger to show to the user. You yourself pointed out the others. Every good programmer of which I know is cognizant of the technique of casting the variable or memory area, from within a debugger, to the actual type so that the debugger shows the value. Are you saying it should be up to Boost to tell the programmer about this technique ? I am not saying it might not be helpful, but I do not think it belongs in the documentation as a general rule since the technique is universal to other similar situations, and not to just one or two Boost libraries.
I agree that it should not be in the Boost documentation. However it *is* something to know and everybody has learnt it at a particular moment. It's one of those tips. Especially for 'difficult' (like templated) datastructures, I can image the number of trees hiding the forrest can be very large. To be short: the boost website could have pointers to good related sites (like for debugging) or have a couple of pages of its own that handle these Tips 'n' Tricks. (PS: I'm fairly new to Boost too, so my appologies if my terminology is off.) agb
Edward Diener <eddielee@tropicsoft.com> writes:
I disagree. Certainly Pierre's experience belies that statement. More generally, variant presents a high-level abstraction, and users aren't necessarily expected to have any idea how it works internally. For the most part, a naive user with a good debugger can explore his program's data structures at will, but unlike almost any other library component, variant is a barrier to the type information the debugger needs.
Variant isn't the only data structure where the actual type stored is not known at compile time and therefore unavailable to the debugger to show to the user. You yourself pointed out the others.
Yes, there are a very few others. And I was wrong about shared_ptr<void>, since the deleter still has the static type info.
Every good programmer of which I know is cognizant of the technique of casting the variable or memory area, from within a debugger, to the actual type so that the debugger shows the value.
So does that make Pierre a bad programmer? I don't think anyone's programming skill should be indicted based on ignorance of a single debugging hack.
Are you saying it should be up to Boost to tell the programmer about this technique ?
No, I'm saying that maybe Boost should tell the user enough about the implementation of variant so that he knows to look at the address of the aligned storage for the type stored there when debugging. While we're at it, I think it would be courteous to mention the cast technique.
I am not saying it might not be helpful, but I do not think it belongs in the documentation as a general rule since the technique is universal to other similar situations, and not to just one or two Boost libraries.
The technique may be universal, but I think the _problem_ is particular to just one or two Boost libraries. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
Anne-Gert Bultena -
David Abrahams -
Edward Diener -
Pierre THIERRY