|
From: <enn...@t-...> - 2004-12-22 07:57:11
|
Hi
Is it possible to give more informations if the memcheck tool
of valgrind is used ?
1.) Type of variable
If there is done a wrong read of a 8 byte data word
I do get this message:
--> ==25832== Invalid read of size 8
It would be nice if valgrind could say the kind of variable:
--> ==25832== Invalid read of size 8 (double)
or
--> ==25832== Invalid read of size 8 (double), did read 4 (float)
2.) At which position of a function call did the error happend?
Which variable was it /or/ Which parameter number was it?
If I do have a function call with many parameters like this one
(or more)
--> fprintf (p_file, "%f %f %f %f %f %f\n", a, b, c, d, e, f);
It would be very helpfully if valgrind could say not only the
line number, but also the parameter number, where the error occurs.
In this example: If "c" would be the error maker than the
additional output should/could be:
... (file.c:45:parameter 5) ...
I do not know if this is possible but it would be very good for faster
determination of the error place, like it is done
if the gnu compiler compiles a source file and says at an error
something like that: "... parameter x of function is wrong"
Thanks for listening
MfG
Enno
|
|
From: Nicholas N. <nj...@ca...> - 2004-12-23 06:11:56
|
On Wed, 22 Dec 2004, Enno Bartels wrote: > I do not know if this is possible but it would be very good for faster > determination of the error place, like it is done > if the gnu compiler compiles a source file and says at an error > something like that: "... parameter x of function is wrong" Gcc can produce better error messages because it works with source code, whereas Valgrind only works with the program's exectuable code + debuggin information. For this reason both the things you ask for are at least difficult to provide, and may be impossible (I'm not sure, perhaps the information could be extracted from the debugging information with some effort.) So, in short, I think it's unlikely that these features will be able to be implemented. I'd be happy to be proven wrong, though. N |
|
From: Dennis L. <pla...@tz...> - 2004-12-23 15:05:36
|
Am Donnerstag, den 23.12.2004, 06:11 +0000 schrieb Nicholas Nethercote: > On Wed, 22 Dec 2004, Enno Bartels wrote: > > > I do not know if this is possible but it would be very good for faster > > determination of the error place, like it is done > > if the gnu compiler compiles a source file and says at an error > > something like that: "... parameter x of function is wrong" > > Gcc can produce better error messages because it works with source code, > whereas Valgrind only works with the program's exectuable code + debuggin > information. For this reason both the things you ask for are at least > difficult to provide, and may be impossible (I'm not sure, perhaps the > information could be extracted from the debugging information with some > effort.) > > So, in short, I think it's unlikely that these features will be able to be > implemented. I'd be happy to be proven wrong, though. Afaik gcc 4 uses some more debugging information which also makes local variable names available. gdb can with all the info embedded when using -g (does dwarf2 output on linux) reconstruct the function parameters, their names and values even without the source, if debug info is included. So I think it would be at least possible to include it within valgrind. But I personally wonder if its worth the work if you can simply attach the debugger in such a case, since most cases were valgrind supports something and you even have the source and attach gdb you easily see what went wrong. Of course thats only my experience from working now since valgrind 1.0 but I also think that including the parsing stuff that gdb does is quite a big piece of work... greets Dennis -- Dennis Lubert <pla...@tz...> |
|
From: Maurice v. d. P. <gri...@ge...> - 2004-12-23 15:43:33
|
On Thu, Dec 23, 2004 at 04:05:47PM +0100, Dennis Lubert wrote: > But I personally wonder if its worth the work if you can simply attach > the debugger in such a case, since most cases were valgrind supports > something and you even have the source and attach gdb you easily see > what went wrong. I have been considering some functionality that could help in the cases where simply attaching gdb isn't very useful. If you're interested, you=20 can take a look at these: http://bugs.kde.org/show_bug.cgi?id=3D92456 http://sourceforge.net/mailarchive/message.php?msg_id=3D9938231 I'm a bit stuck at the moment. My message from November 27 describes=20 the problem. If this is ever going to work, I'd probably still need to some debug=20 info parsing to figure out function/variable names, but I'll cross that bridge when I come to it. Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Tom H. <th...@cy...> - 2004-12-23 15:56:20
|
In message <200...@kf...>
Maurice van der Pot <gri...@ge...> wrote:
> If this is ever going to work, I'd probably still need to some debug
> info parsing to figure out function/variable names, but I'll cross that
> bridge when I come to it.
There is already code in valgrind to parse the debug information and
figure out the function names and (for stabs only at present) the
variable names.
One day somebody will get around to making the DWARF reader obtain the
variable information...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|