This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: c++/375: debug problems when there are multiple expansions of same template
- From: Frank Schmitt <ich at frank-schmitt dot net>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 11 Aug 2005 21:18:07 -0000
- Subject: Re: c++/375: debug problems when there are multiple expansions of same template
- Reply-to: Frank Schmitt <ich at frank-schmitt dot net>
The following reply was made to PR c++/375; it has been noted by GNATS.
From: Frank Schmitt <ich@frank-schmitt.net>
To: gdb-gnats@sources.redhat.com
Cc:
Subject: Re: c++/375: debug problems when there are multiple expansions of same template
Date: Thu, 11 Aug 2005 23:13:05 +0200
Is there any chance that this issue will be fixed?
We are working with 3D images with either 1, 2 or 4 bytes gray value
depth. Because of this, almost all our functions are templatized and
expanded three times (with unsigned char, unsigned short and unsigned
int), in the case of functions working with two images, I often even
have nine (3*3) expansions.
Currently gdb is almost unusable for me. I can set a breakpoint at the
beginning of a function (by saying rbreak functionName which finds all
expansions), but there's no way to set a breakpoint inside a function as
gdb just chooses one template expansion randomly. Even 'until' in loops
often doesn't work, neither does 'break +lineoffset' when I'm already in
the function. So if I have a loop with some 1.000.000 iterations (which
you often have if you run through images as large as 512*512*256), all I
can do is saying something like 1000000 n, which is dead slow and
imposes the big danger to miss the point which should be inspected.
If this happens I normally scream, knock my head on the table, go and
have a cigarette, boot windows, do a CVS update, start Visual Studio,
compile, wait, recognize that I forgot to checkin, scream, knock my head
on the table real hard, boot Linux, checkin, boot Windows, do cvs
update, start Visual Studio, compile, wait, work around incompabilities
of the braindead compiler, compile, wait, debug, checkin, go home and
drink a beer.
You can't honestly want that? :-)