On 07/20/2015 08:11 PM, Jakub Jelinek wrote:
On Mon, Jul 20, 2015 at 07:55:46PM +0300, Nikolai Bozhenov wrote:
On 07/17/2015 08:31 PM, Michael Eager wrote:
On 07/17/2015 03:43 AM, Nikolai Bozhenov wrote:
Consider the following example:
1 extern void bar(int *i1, int *i2, int *i3);
2
3 int __attribute__((noinline)) foo(int i1, int i2) {
4 int a, b, c;
5 a = i1 << i2;
6 b = (i1 + i2) * i1;
7 c = (b + i1);
8 bar(&a, &b, &c);
9 }
10
11 int main() {
12 foo(42, 12);
13 }
First of all, -fvar-tracking-uninit is misdesigned mess that really should
have never been added to GCC, so please don't consider DW_OP_GNU_uninit
as something that should be used in any approach for this.
Thanks for your reply, Jakub!
So, I take it -fvar-tracking-uninit is completely useless/broken for
now and is likely to be removed in future versions of GCC, isn't it?
Anyway, it seems that I was trying to use the wrong tool to solve the
problem. In my initial example I got confusing results because
unconditionally initialized variables were in fact uninitialized at
the point where I expected them to be initialized (at the last line of
the function). But in fact, the confusion was caused by reordering of
operations rather than by uninitialized variables. In the following
slightly modified example I would face the same confusion at line 11
(because likewise new values wouldn't be yet assigned to the
variables) though there are no uninitialized variables any more:
3 int foo(int i1, int i2) {
4 int a = getvalue();
5 int b = getvalue();
6 int c = getvalue();
7 if (baz()) {
8 a = i1 << i2;
9 b = (i1 + i2) * i1;
10 c = (b + i1);
11 bar(&a, &b, &c);
12 }
. . .
I mean that when debugging an optimized code the main problem is that
operations are heavily reordered. Therefore, to simplify debugging one
would like to determine what source code parts have been fully
executed, what parts are currently being executed and what parts are
yet to be executed.
In the latter example if one could determine that lines 8 through 10
hadn't been completely executed when the breakpoint at line 11 was
hit, any unexpected values for variables a, b, c wouldn't cause much
confusion because it would be clear that they simply haven't got new
values yet. Then, one could set the breakpoint at some following
instruction and get values of interesting variables after execution of
corresponding source lines is finished.
Nikolai
