|
From: Guilhem B. <gu...@my...> - 2005-03-29 13:16:55
|
Hi,
"It would be great if" (TM) Valgrind could report which bit was not
initialized, not only which byte. For example:
#include <stdio.h>
main()
{
char *buf2;
buf2= (char*)malloc(1);
(*buf2)|= 1|2|4|16|32|64|128;
if (*buf2)
printf("test\n");
}
Here bit 4 ("|8" is missing) is the only one not initialized.
[guilhem 15:09 /home/mysql_src/tmp] gcc -g b.c;valgrind ./a.out
==24801== Memcheck, a memory error detector for x86-linux.
==24801== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==24801== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==24801== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==24801== For more details, rerun with: -v
==24801==
==24801== Conditional jump or move depends on uninitialised value(s)
==24801== at 0x80483FE: main (b.c:7)
If in this error message, Valgrind could say the position of the first
bit not initialized, it would really be helpful. In the MySQL code we
have some variable like this:
uint flags; // 32 "flags"
In some piece of code we set a certain bit of "flags", in some other
separate piece of code we set another bit, etc, and when later we get
"uninitialized value" when using the variable "flags" as a whole, like
this:
if (flags)
it's sometimes hard to know which piece of code is guilty for not
doing its job.
I would like to ask:
does there currently exist some option to make Valgrind print this
information? If not:
is it in the plans? would it be hard to code? would you be
interested in a contributed patch for it? would you have any hints
on how to best do it?
Thanks!
Guilhem
|
|
From: Julian S. <js...@ac...> - 2005-03-29 15:54:08
|
> ==24801== Conditional jump or move depends on uninitialised value(s) > ==24801== at 0x80483FE: main (b.c:7) > > If in this error message, Valgrind could say the position of the first > bit not initialized, it would really be helpful. That would be difficult to implement -- I can't see any easy way, at least not without large changes to memcheck. The problem is that by the time the error message is shown, the bit-level details of the byte causing the problem have been lost. V only knows that the simulated CPU's condition codes might be undefined; the information about how they came to be undefined -- which will be as a result of a cmpb instruction, maybe -- will have been lost. Another way to say it is: the message is emitted when V sees a use of undefined CPU condition codes for a conditional branch or move. Those condition codes became undefined as a result of an arithmetic operation (compare?) with your undefined byte as an operand. The compare and the resulting branch could be far apart -- usually they are not, but there is nothing guaranteeing that -- and so the info you need is not readily at hand. That said, it's interesting to ponder if it is possible to do something better in the common case. The new IR used in 3.0 usually results in Vex being able to recover the actual C-code condition a branch depends on (x == y, x > y, x >= y, etc) and it might be possible to do something better for those cases. J |