This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Better debugging with!
- From: Alec Teal <a dot teal at warwick dot ac dot uk>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 23 Jan 2013 10:31:10 +0000
- Subject: Better debugging with!
I've been thinking about this for a while and it can't hurt to share it
(it'd become shared eventually anyway) and someone might thing "good idea":
Obviously -g makes gcc embed a lot of information in the result that is
clear already why not that bit more? Arrays will always be integer sized
(4 bytes) (you could go long...) and it'd be really convenient if you
didn't have to tell gdb how big of an array to pretend it is, why not
tell it in code? This'd be great! It already knows about pointers so
this is just a simple step:
int n = 10;
#GDB_PAY_ATTENTION int n
MyType* arrayOfSorts = (MyType*) malloc(n*sizeof(MyType));
(not a word about calloc)
the int after ATTENTION is just if you had MASSIVE arrays beyond the
bounds of an unsigned int (could happen, who am I to prevent that, in
theory) perhaps int could be implicit, followed by the variable name or
constant size of the array.
This should just tell GDB to pay attention to the NEXT STATEMENT ONLY
and the first statement on that line (incase you can think of some weird
way this would mean re-writing something currently valid):
struct Vertex {
float x;
float y;
float z;
};
int n = 100*3;
#GDB_PAY_ATTENTION n
float* points = malloc(n*sizeof(float));
int k = n / 3;
#GDB_PAY_ATTENTION k
Vertex* vertices = (Vertex*) points;
Obviously not GDB_PAY_ATTENTION, that's supposed to be humour because I
have no ideas for a name yet.
I also see no reason not to allow "n" to be an expression? with the K
above an optimizer will have it's way with that anyway as k isn't used
after, you get the idea!
Alec