This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]