|
From: Josef W. <Jos...@gm...> - 2003-08-05 10:14:07
|
Hi, On Tuesday 05 August 2003 11:23, Nicholas Nethercote wrote: > On Tue, 5 Aug 2003 Bor...@pd... wrote: > > With the above mentioned method, the user would be sure, that this is a > > bug of his program and not one of valgrind...which is really usefull > [...] > There's an element of trust involved with using any programming tool. For > example, if your program is behaving unexpectedly, do you suspect your > program, or the compiler? It's a similar issue here -- at a certain > level, you have to trust the tool you are using. I'm not so sure about this. If requested, a tool should provide as much details as possible to allow the user to check for himself if the error is in the tool or his own program. And this *is* difficult to do. In the case of a faulting compiler, the user can have a look at the disassembled code with GDB; he even can single step assembler. IMHO, that's one crucial point with using a debugger. I recently introduced an annotated assembler view into KCachegrind and added an option to calltree to dump cost per instruction. Before this, I *had* to trust my tool for correct summation per source line. Now I actually can check for correctness, as with annotated assembler, event counts (instruction fetches, cache misses) are much more understandable. Another example: I skip PLT sections in call chains, without giving feedback to the user. This is *bad*, I will have to change it: Nobody will understand from dissassembled code, why a CALL leads to 2 calls to unrelated positions. Back to Valgrind: Valgrind's SEGFAULT handler should give out a precise error message after a SEGFAULT is catched, that this was because of application code. Obviously, Valgrind already contains such a message when the SEGFAULT appears in Valgrind code. The addition should be easy. Perhaps there should be an option to give out a chunk of dissassembled code within Valgrinds error message, together with a dump of register content? This would allow the user to check if the dissassembled code really was able to raise e.g. an SEGFAULT. > Why should you trust it? Well, if lots of other people use it, that's a > good sign. Also, if you use the tool yourself for a while, you'll soon > get a feel for how trustworthy it is. Hmmm... Josef |