Eclipse/CDT, when hovering over a variable in a source pane, will display 0x0 as the value for optimized-out variables that don't show up in the Variables pane. This appears to be an underlying GDB problem with the MI interface it uses to talk to external front ends. Here's a transcript running “gdb -interpreter=mi”, and typing a mix of normal and MI commands at it: (gdb) p ecs &"p ecs\n" ~"$1 = <value optimized out>\n" ^done (gdb) -data-evaluate-expression ecs ^done,value="0x0" So the normal command-line command does the right thing, but the MI version does not. This appears to be because the command-line path calls print_formatted(), which calls value_print(), which calls value_check_printable(), which checks for value_optimized_out(). The MI path calls val_print() directly, which doesn't check.
Subject: Re: New: MI -data-evaluate-expression prints optimized-out variable value as 0x0 > Eclipse/CDT, when hovering over a variable in a source pane, will display > 0x0 as the value for optimized-out variables that don't show up in the > Variables pane. > > This appears to be an underlying GDB problem with the MI interface it uses > to talk to external front ends. Here's a transcript running “gdb > -interpreter=mi”, and typing a mix of normal and MI commands at it: > > (gdb) p ecs > > &"p ecs\n" > > ~"$1 = <value optimized out>\n" > > ^done > > (gdb) -data-evaluate-expression ecs > > ^done,value="0x0" Does this change DTRT? -- Nick http://www.inet.net.nz/~nickrob Index: mi-main.c =================================================================== RCS file: /cvs/src/src/gdb/mi/mi-main.c,v retrieving revision 1.142 diff -p -u -p -r1.142 mi-main.c --- mi-main.c 14 Jan 2009 15:21:55 -0000 1.142 +++ mi-main.c 16 Jan 2009 22:16:03 -0000 @@ -776,10 +776,7 @@ mi_cmd_data_evaluate_expression (char *c /* Print the result of the expression evaluation. */ get_user_print_options (&opts); opts.deref_ref = 0; - val_print (value_type (val), value_contents (val), - value_embedded_offset (val), VALUE_ADDRESS (val), - stb->stream, 0, &opts, current_language); - + common_val_print (val, stb->stream, 0, &opts, current_language); ui_out_field_stream (uiout, "value", stb); ui_out_stream_delete (stb);
Subject: RE: MI -data-evaluate-expression prints optimized-out variable value as 0x0 Yes and no. Your source base seems to have changed from the 6.8 we started with. My diff is: ==== //tilera/main/tools/gnu/gdb/mi/mi-main.c#3 - /u/rschooler/p4/tools/gnu/gdb/mi/mi-main.c ==== @@ -670,9 +670,7 @@ val = evaluate_expression (expr); /* Print the result of the expression evaluation. */ - val_print (value_type (val), value_contents (val), - value_embedded_offset (val), VALUE_ADDRESS (val), - stb->stream, 0, 0, 0, 0); + common_val_print (val, stb->stream, 0, 0, 0, 0); ui_out_field_stream (uiout, "value", stb); ui_out_stream_delete (stb); This worked for me. Should I go with this change now, or wait for some more official patch, with regression testing, etc.? Thanks, -- Richard Richard Schooler VP Software Engineering Tilera Corp. 1900 West Park Drive, Westborough MA 01581 Tel.: +1 (508) 616 9300 x236 Cell: +1 (617) 233 8425 > -----Original Message----- > From: nickrob at snap dot net dot nz [mailto:sourceware- > bugzilla@sourceware.org] > Sent: Friday, January 16, 2009 5:18 PM > To: Richard Schooler > Subject: [Bug mi/9752] MI -data-evaluate-expression prints optimized-out > variable value as 0x0 > > > ------- Additional Comments From nickrob at snap dot net dot nz 2009-01- > 16 22:17 ------- > Subject: Re: New: MI -data-evaluate-expression prints optimized-out > variable value as 0x0 > > > Eclipse/CDT, when hovering over a variable in a source pane, will > display > > 0x0 as the value for optimized-out variables that don't show up in the > > Variables pane. > > > > This appears to be an underlying GDB problem with the MI interface it > uses > > to talk to external front ends. Here's a transcript running "gdb > > -interpreter=mi", and typing a mix of normal and MI commands at it: > > > > (gdb) p ecs > > > > &"p ecs\n" > > > > ~"$1 = <value optimized out>\n" > > > > ^done > > > > (gdb) -data-evaluate-expression ecs > > > > ^done,value="0x0" > > Does this change DTRT? > > -- > Nick > http://www.inet.net.nz/~nickrob > > > Index: mi-main.c > =================================================================== > RCS file: /cvs/src/src/gdb/mi/mi-main.c,v > retrieving revision 1.142 > diff -p -u -p -r1.142 mi-main.c > --- mi-main.c 14 Jan 2009 15:21:55 -0000 1.142 > +++ mi-main.c 16 Jan 2009 22:16:03 -0000 > @@ -776,10 +776,7 @@ mi_cmd_data_evaluate_expression (char *c > /* Print the result of the expression evaluation. */ > get_user_print_options (&opts); > opts.deref_ref = 0; > - val_print (value_type (val), value_contents (val), > - value_embedded_offset (val), VALUE_ADDRESS (val), > - stb->stream, 0, &opts, current_language); > - > + common_val_print (val, stb->stream, 0, &opts, current_language); > ui_out_field_stream (uiout, "value", stb); > ui_out_stream_delete (stb); > > > -- > > > http://sourceware.org/bugzilla/show_bug.cgi?id=9752 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter.
Subject: RE: MI -data-evaluate-expression prints optimized-out variable value as 0x0 Richard Schooler writes: > Yes and no. Your source base seems to have changed from the 6.8 we > started with. I've started with gdb in current CVS. > My diff is: > > ==== //tilera/main/tools/gnu/gdb/mi/mi-main.c#3 - > /u/rschooler/p4/tools/gnu/gdb/mi/mi-main.c ==== > @@ -670,9 +670,7 @@ > val = evaluate_expression (expr); > > /* Print the result of the expression evaluation. */ > - val_print (value_type (val), value_contents (val), > - value_embedded_offset (val), VALUE_ADDRESS (val), > - stb->stream, 0, 0, 0, 0); > + common_val_print (val, stb->stream, 0, 0, 0, 0); > > ui_out_field_stream (uiout, "value", stb); > ui_out_stream_delete (stb); > > This worked for me. Should I go with this change now, or wait for some > more official patch, with regression testing, etc.? Well, there probably won't be a backport to 6.8, so if that's what you're using, you need to make your own patch. For my patch to get into GDB for the next release (7.0), it needs to be approved by the MI or a global maintainer.
Is this patch still pending?
Subject: MI -data-evaluate-expression prints optimized-out variable value as 0x0 > Is this patch still pending? I probably should have confirmed the bug and changed the status to NEW but pending is not listed as a status. It's not been resolved in bugzilla and it's quite easy to see that it's not been fixed: compile a simple program with function calls with -O (or -O2), stop in main using GDB with MI and you should see something like: -stack-list-locals 1 ^done,locals=[{name="n1",value="0"},{name="n2",value="4195696"},{name="n3",value="0"},{name="ptr",value="<value optimized out>"},{name="a",value="<value optimized out>"}] (gdb) -data-evaluate-expression ptr ^done,value="0x0" (gdb) where (in this case) ptr and a are the arguments of function calls.
Ok, thanks. I didn't see this on gdb-patches. Anyway, it is ok with a test case.
Subject: MI -data-evaluate-expression prints optimized-out variable value as 0x0 > Ok, thanks. > I didn't see this on gdb-patches. > Anyway, it is ok with a test case. This patch just replaces the call to val_print with one to common_val_print. There's no test for the MI command -stack-list-locals when values are optimized out and presumably existing tests will pick up any regressions for this circumstance. So, what would the be the purpose of a test case in this particular instance?
The purpose of a test in this case is to prevent regressions in the future.
Subject: MI -data-evaluate-expression prints optimized-out variable value as 0x0 > The purpose of a test in this case is to prevent regressions > in the future. Apart from the fact that a test here would involve far more work than the patch itself (as it probably needs a separate executable compiled with optimisation), every test adds to the time it takes the testsuite to run. I have written many test cases in the past, but I can't see the point here, so I don't plan to write one.
Apparently fixed in 7.2.