Better debugging with!

Alec Teal a.teal@warwick.ac.uk
Wed Jan 23 10:31:00 GMT 2013


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



More information about the Gcc mailing list