|
From: Bryan M. <om...@br...> - 2006-08-28 21:57:25
|
Julian Seward wrote:
>> Looking at the two programs side by side, I think the real crux of it is
>> the differing epilog code. I think I am falling over trying to detect
>> when there is a value being returned through the accumulator.
>
> This sounds like a dataflow/liveness problem. So, let me unwind
> one more level. Why do you want to know whether the accumulator
> contains a live vs dead value at the point the function returns?
> What are you going to do with that info?
>
> J
>
Julian,
that's exactly the problem. If the accumulator holds a pointer to a
memory block and is live, it should be left alone and tracked out of the
function. If it is dead, it should be culled as the function exits,
possibly generating a leak report if it is the final pointer to that block.
If the pointer is dead but is left until it is over-written, the
location of the leak report is inaccurate.
The ability to detect the dead value allows function scope related
checking for leaks. As an example (this is scope2.c in the test directory):
#include <stdlib.h>
static void func1(void)
{
char *pointer = 0;
pointer = malloc(64); /* Line 7 */
return;
} /* Leak report Line 10 */
int main(int argc, char *argv[])
{
func1();
return 0; /* Line 16 */
}
At line 7, the malloc() call returns the pointer in the accumulator
which is then also saved into the stack variable "pointer". As the
function exits, the stack unwinds, removing the reference in "pointer"
but the accumulator will still hold a reference. If the accumulator is
detected as being dead, a leak report will be generated at line 10 as we
remove the reference it is holding and discover it is the last one. If
we don't invalidate the accumulator, we get the leak report at line 16
instead when the reference is overwritten by 0 in order to be returned
by main().
A report at line 16 is not only inferior to a report at line 10, it is
not going to provide the clarity that Omega should supply in it's goal
to assist in tracking down memory leaks: a report at line 10 makes it
pretty obvious that something went out of scope whilst a report at line
16 will leave most people scratching their heads.
It's pretty fundamental to the whole thing which is why I could do with
a robust method for determining when to cull registers on exit and when
to leave them alone - the ABI is simply not enough.
Hope that explains it,
Bryan
|