qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Tracking unfreed tcg temps


From: Peter Maydell
Subject: [Qemu-devel] Tracking unfreed tcg temps
Date: Tue, 11 Jan 2011 06:09:06 -0600

The ARM target-arm/translate.c file has some code in it which tries to
track the number of TCG temporaries allocated during translation of an
ARM instruction and complain if they are not freed by the end of that
instruction. So new_tmp() allocates a temp with tcg_temp_new_i32() and
increments the count; dead_tmp() calls tcg_temp_free() and decrements
the count. If at the end of translating an instruction the count isn't
zero we print a warning:

  fprintf(stderr, "Internal resource leak before %08x\n", dc->pc);

However there are a lot of code paths which will trigger this warning;
generally these are for invalid encodings where we only notice that
the opcode is invalid after having loaded the input operands, so we've
allocated a temp but the generate-UNDEF-exception exit path doesn't
free it.

tcg/README says that failure to free a temporary is not very harmful,
because it just means more memory usage and slower translation. (On
the other hand there seems to be a hardcoded TCG_MAX_TEMPS limit on
the number of temporaries, which suggests that freeing temporaries is
important and the README is misleading?)

So what's the best thing to do with this temporary-tracking code?

(1) just get rid of it as it is misguided

(2) tweak it so that we don't complain about non-freed temps if this
is the end of the TB anyway [since the invalid-encoding case will
always result in ending the TB]

(3) rework all the code which catches invalid encodings so that we can
identify undefined instructions before we have done any of the
preparatory loading of operands that is causing the warning to trigger

[If it is useful to track not-freed-temps like this shouldn't the
code be in tcg and not ad-hoc in target-arm anyway?]

This question is motivated by the meego-qemu tree including a set
of changes which go down path (3), which I'm not sure what to do
with...

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]