[RFC 06/12] entryval: Display @entry parameters in bt full

[RFC 06/12] entryval: Display @entry parameters in bt full

[Jan Kratochvil]

Hi,

this is a first kind of access to the entry values.  A (non-testcase) demo is:

#8  0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438
	p@entry = 0x22b5720 "maintenance internal-error "
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	arg = <optimized out>
	cleanup = 0x28333b0
	c = 0x24996d0
	flang = <optimized out>
	warned = 0
	line = 0x22b5720 "maintenance internal-error "

p@entry is not particularly useful here because the `line' local variable
contains the same.  One can imagine in other real world applications it can be
useful - for a backtrace sent by user where you do not have a reproducer and/or
the core file (the case of ABRT bugreports).

The parameter@entry lines are not displayed if they are not useful.  Therefore
if they would display the same value as the current parameter value or if GDB
cannot successfully determine the entry value.

It is displayed by `bt full' and `info args'.  RFC is whether it is not too
verbose and/or if it should not be displayed some way even with normal `bt'.
Also whether there should be some `set' variable to forget about @entry values.


Thanks,
Jan


gdb/
2011-07-18  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Display @entry parameter values (without references).
	* doc/gdb.texinfo (backtrace full, info args): Mention @entry suffix.
	* dwarf2expr.c (dwarf_block_to_fb_offset): New function.
	* dwarf2expr.h (dwarf_block_to_fb_offset): New declaration.
	* dwarf2loc.c (dwarf2_find_location_expression): Support location list
	entry record.
	(dwarf_entry_parameter_to_value): New function.
	(dwarf2_locexpr_funcs): New NULL for read_variable_at_entry.
	(value_of_dwarf_reg_entry, loclist_read_variable_at_entry): New
	functions.
	(dwarf2_loclist_funcs): Install loclist_read_variable_at_entry.
	* f-valprint.c (info_common_command): Add PVAVD_IS_NOT_ARGUMENT to the
	print_variable_and_value call.
	* printcmd.c (print_variable_and_value): New parameter print_argument,
	describe it.  Print @entry parameter value when appropriate.
	* stack.c (struct print_variable_and_value_data): New field
	print_argument.
	(do_print_variable_and_value): Pass the print_argument parameter.
	(print_frame_local_vars): Change the parameter num_tabs to from_frame.
	Print @entry parameters if FROM_FRAME.
	(print_frame_arg_vars): Specify PVAVD_ARGUMENT_PRINT_BOTH.
	* symtab.h (struct symbol_computed_ops): New field
	read_variable_at_entry.
	* value.h (enum print_argument): New.
	(print_variable_and_value): New parameter print_argument.

gdb/testsuite/
2011-07-18  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Display @entry parameter values (without references).
	* gdb.arch/amd64-entry-value.cc (stacktest, reference): New functions.
	(main): New variable refvar, call stacktest and reference.
	* gdb.arch/amd64-entry-value.exp: New breakpoints stacktest,
	breakhere_stacktest, reference and breakhere_reference.
	(entry: bt full): Update for @entry.
	(entry_stack: stacktest, entry_stack: bt full at entry)
	(entry_stack: breakhere_stacktest, entry_stack: bt full)
	(entry_stack: p s1, entry_stack: p s2, entry_reference: reference)
	(entry_reference: bt full at entry)
	(entry_reference: breakhere_reference, entry_reference: bt full)
	(entry_reference: ptype refparam, entry_reference: p refparam)
	(entry_reference: p refcopy): New tests.

--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -5947,8 +5947,13 @@ Similar, but print only the outermost @var{n} frames.
 @itemx bt full
 @itemx bt full @var{n}
 @itemx bt full -@var{n}
-Print the values of the local variables also.  @var{n} specifies the
-number of frames to print, as described above.
+Print the values of the local variables also.
+
+Names with appended @code{@@entry} show values of function parameters at the
+time the function got called.  The @code{@@entry} parameter line is not shown
+when the entry value is not available.
+
+@var{n} specifies the number of frames to print, as described above.
 @end table
 
 @kindex where
@@ -6223,6 +6228,10 @@ architectures) that you specify in the @code{frame} command.
 @item info args
 Print the arguments of the selected frame, each on a separate line.
 
+Names with appended @code{@@entry} show values of function parameters at the
+time the function got called.  The @code{@@entry} parameter line is not shown
+when the entry value is not available.
+
 @item info locals
 @kindex info locals
 Print the local variables of the selected frame, each on a separate
--- a/gdb/dwarf2expr.c
+++ b/gdb/dwarf2expr.c
@@ -602,6 +602,30 @@ dwarf_block_to_sp_offset (struct gdbarch *gdbarch, const gdb_byte *buf,
   return 1;
 }
 
+/* If <BUF..BUF_END] contains DW_FORM_block* with single DW_OP_fbreg(X) fill
+   in FB_OFFSET_RETURN with the X offset and return 1.  Otherwise return 0.  */
+
+int
+dwarf_block_to_fb_offset (const gdb_byte *buf, const gdb_byte *buf_end,
+			  CORE_ADDR *fb_offset_return)
+{
+  LONGEST fb_offset;
+
+  if (buf_end <= buf)
+    return 0;
+
+  if (*buf != DW_OP_fbreg)
+    return 0;
+  buf++;
+
+  buf = read_sleb128 (buf, buf_end, &fb_offset);
+  *fb_offset_return = fb_offset;
+  if (buf != buf_end || fb_offset != (LONGEST) *fb_offset_return)
+    return 0;
+
+  return 1;
+}
+
 /* The engine for the expression evaluator.  Using the context in CTX,
    evaluate the expression between OP_PTR and OP_END.  */
 
--- a/gdb/dwarf2expr.h
+++ b/gdb/dwarf2expr.h
@@ -270,6 +270,9 @@ int dwarf_block_to_sp_offset (struct gdbarch *gdbarch, const gdb_byte *buf,
 			      const gdb_byte *buf_end,
 			      CORE_ADDR *sp_offset_return);
 
+int dwarf_block_to_fb_offset (const gdb_byte *buf, const gdb_byte *buf_end,
+			      CORE_ADDR *fb_offset_return);
+
 int dwarf_block_to_dwarf_reg_deref (const gdb_byte *buf,
 				    const gdb_byte *buf_end,
 				    CORE_ADDR *deref_size_return);
--- a/gdb/dwarf2loc.c
+++ b/gdb/dwarf2loc.c
@@ -121,6 +121,24 @@ dwarf2_find_location_expression (struct dwarf2_loclist_baton *baton,
       length = extract_unsigned_integer (loc_ptr, 2, byte_order);
       loc_ptr += 2;
 
+      if (low == high && pc == low)
+	{
+	  /* This is entry PC record present only at entry point
+	     of a function.  Verify it is really the function entry point.  */
+
+	  struct block *pc_block = block_for_pc (pc);
+	  struct symbol *pc_func = NULL;
+
+	  if (pc_block)
+	    pc_func = block_linkage_function (pc_block);
+
+	  if (pc_func && pc == BLOCK_START (SYMBOL_BLOCK_VALUE (pc_func)))
+	    {
+	      *locexpr_length = length;
+	      return loc_ptr;
+	    }
+	}
+
       if (pc >= low && pc < high)
 	{
 	  *locexpr_length = length;
@@ -913,6 +931,35 @@ dwarf_entry_parameter_to_block (struct call_site_parameter *parameter,
   return parameter->call_site_data_value;
 }
 
+/* Return value for PARAMETER matching DEREF_SIZE, see
+   dwarf_entry_parameter_to_block for the description of these parameters.
+
+   TYPE and CALLER_FRAME specify how to evaluate the DWARF block into returned
+   struct value.
+
+   Function always returns non-NULL, non-optimized out value.  It throws
+   NOT_FOUND_ERROR if it cannot resolve the value for any reason.  */
+
+static struct value *
+dwarf_entry_parameter_to_value (struct call_site_parameter *parameter,
+				CORE_ADDR deref_size, struct type *type,
+				struct frame_info *caller_frame)
+{
+  struct dwarf2_locexpr_baton *dwarf_block;
+  gdb_byte *data;
+
+  dwarf_block = dwarf_entry_parameter_to_block (parameter, deref_size);
+
+  /* DW_AT_GNU_call_site_value is a DWARF expression, not a DWARF
+     location.  */
+  data = alloca (dwarf_block->size + 1);
+  memcpy (data, dwarf_block->data, dwarf_block->size);
+  data[dwarf_block->size] = DW_OP_stack_value;
+
+  return dwarf2_evaluate_loc_desc (type, caller_frame, data,
+				   dwarf_block->size + 1, dwarf_block->per_cu);
+}
+
 /* Execute DWARF_BLOCK for caller of the CTX's frame.  CTX must be of
    dwarf_expr_ctx_funcs kind.  See DWARF_REG, FB_OFFSET and DEREF_SIZE
    description at struct dwarf_expr_context_funcs->push_dwarf_reg_entry_value.
@@ -3500,6 +3547,7 @@ locexpr_tracepoint_var_ref (struct symbol *symbol, struct gdbarch *gdbarch,
    evaluator.  */
 const struct symbol_computed_ops dwarf2_locexpr_funcs = {
   locexpr_read_variable,
+  NULL,				/* read_variable_at_entry */
   locexpr_read_needs_frame,
   locexpr_describe_location,
   locexpr_tracepoint_var_ref
@@ -3530,6 +3578,64 @@ loclist_read_variable (struct symbol *symbol, struct frame_info *frame)
   return val;
 }
 
+/* Return value of parameter of TYPE at (callee) FRAME which at function entry
+   point.  Parameter has been passed in DWARF_REG or FB_OFFSET, see their
+   description at struct dwarf_expr_context_funcs->push_dwarf_reg_entry_value.
+
+   Function always returns non-NULL, non-optimized out value.  It throws
+   NOT_FOUND_ERROR if it cannot resolve the value for any reason.  */
+
+static struct value *
+value_of_dwarf_reg_entry (struct type *type, struct frame_info *frame,
+			  int dwarf_reg, CORE_ADDR fb_offset)
+{
+  struct frame_info *caller_frame = get_prev_frame (frame);
+  struct call_site_parameter *parameter;
+
+  parameter = dwarf_expr_dwarf_reg_entry_value (frame, dwarf_reg, fb_offset);
+
+  return dwarf_entry_parameter_to_value (parameter, -1 /* deref_size */, type,
+					 caller_frame);
+}
+
+/* Read variable SYMBOL like loclist_read_variable at (callee) FRAME's function
+   entry.  SYMBOL should be a function parameter, otherwise NOT_FOUND_ERROR
+   will be thrown.
+
+   Function always returns non-NULL value, it may be marked optimized out if
+   inferior frame information is not available.  It throws NOT_FOUND_ERROR if
+   it cannot resolve the parameter for any reason.  */
+
+static struct value *
+loclist_read_variable_at_entry (struct symbol *symbol, struct frame_info *frame)
+{
+  struct dwarf2_loclist_baton *dlbaton = SYMBOL_LOCATION_BATON (symbol);
+  struct value *val;
+  const gdb_byte *data;
+  size_t size;
+  int dwarf_reg;
+  CORE_ADDR deref_size, pc, fb_offset;
+
+  if (frame == NULL || !get_frame_func_if_available (frame, &pc))
+    return allocate_optimized_out_value (SYMBOL_TYPE (symbol));
+
+  data = dwarf2_find_location_expression (dlbaton, &size, pc);
+  if (data == NULL)
+    return allocate_optimized_out_value (SYMBOL_TYPE (symbol));
+
+  dwarf_reg = dwarf_block_to_dwarf_reg (data, data + size);
+  if (dwarf_reg != -1)
+    return value_of_dwarf_reg_entry (SYMBOL_TYPE (symbol), frame, dwarf_reg,
+				     0 /* unused */);
+
+  if (dwarf_block_to_fb_offset (data, data + size, &fb_offset))
+    return value_of_dwarf_reg_entry (SYMBOL_TYPE (symbol), frame, -1,
+				     fb_offset);
+
+  error (_("DWARF-2 expression error: DW_OP_GNU_entry_value is supported only "
+           "for single DW_OP_reg* or for DW_OP_fbreg(*)"));
+}
+
 /* Return non-zero iff we need a frame to evaluate SYMBOL.  */
 static int
 loclist_read_needs_frame (struct symbol *symbol)
@@ -3649,6 +3755,7 @@ loclist_tracepoint_var_ref (struct symbol *symbol, struct gdbarch *gdbarch,
    evaluator and location lists.  */
 const struct symbol_computed_ops dwarf2_loclist_funcs = {
   loclist_read_variable,
+  loclist_read_variable_at_entry,
   loclist_read_needs_frame,
   loclist_describe_location,
   loclist_tracepoint_var_ref
--- a/gdb/f-valprint.c
+++ b/gdb/f-valprint.c
@@ -610,7 +610,8 @@ info_common_command (char *comname, int from_tty)
 
       while (entry != NULL)
 	{
-	  print_variable_and_value (NULL, entry->symbol, fi, gdb_stdout, 0);
+	  print_variable_and_value (NULL, entry->symbol, fi, gdb_stdout, 0,
+				    PVAVD_IS_NOT_ARGUMENT);
 	  entry = entry->next;
 	}
     }
--- a/gdb/printcmd.c
+++ b/gdb/printcmd.c
@@ -1939,32 +1939,74 @@ clear_dangling_display_expressions (struct so_list *solib)
    struct symbol.  NAME is the name to print; if NULL then VAR's print
    name will be used.  STREAM is the ui_file on which to print the
    value.  INDENT specifies the number of indent levels to print
-   before printing the variable name.  */
+   before printing the variable name.  PRINT_ARGUMENT specifies whether @entry
+   kind of function parameters should be printed.  */
 
 void
 print_variable_and_value (const char *name, struct symbol *var,
 			  struct frame_info *frame,
-			  struct ui_file *stream, int indent)
+			  struct ui_file *stream, int indent,
+			  enum print_argument print_argument)
 {
   volatile struct gdb_exception except;
 
   if (!name)
     name = SYMBOL_PRINT_NAME (var);
 
-  fprintf_filtered (stream, "%s%s = ", n_spaces (2 * indent), name);
   TRY_CATCH (except, RETURN_MASK_ERROR)
     {
-      struct value *val;
+      struct value *val, *entryval = NULL;
       struct value_print_options opts;
 
       val = read_var_value (var, frame);
       get_user_print_options (&opts);
-      common_val_print (val, stream, indent, &opts, current_language);
+
+      if (print_argument != PVAVD_IS_NOT_ARGUMENT
+	  && SYMBOL_CLASS (var) == LOC_COMPUTED
+	  && SYMBOL_COMPUTED_OPS (var)->read_variable_at_entry != NULL)
+	{
+	  const struct symbol_computed_ops *ops;
+	  unsigned len = TYPE_LENGTH (value_type (val));
+	  volatile struct gdb_exception entryval_ex;
+
+	  ops = SYMBOL_COMPUTED_OPS (var);
+
+	  TRY_CATCH (entryval_ex, RETURN_MASK_ERROR)
+	    {
+	      entryval = ops->read_variable_at_entry (var, frame);
+	    }
+
+	  if (entryval_ex.reason < 0 || value_optimized_out (entryval))
+	    entryval = NULL;
+	  else
+	    {
+	      if (!value_optimized_out (val) && value_lazy (val))
+		value_fetch_lazy (val);
+	      if (!value_optimized_out (val) && value_lazy (entryval))
+		value_fetch_lazy (entryval);
+	      if (!value_optimized_out (val)
+		  && value_available_contents_eq (val, 0, entryval, 0, len))
+		entryval = NULL;
+	    }
+	}
+
+      if (print_argument != PVAVD_ARGUMENT_PRINT_ENTRYVAL_ONLY)
+	{
+	  fprintf_filtered (stream, "%s%s = ", n_spaces (2 * indent), name);
+	  common_val_print (val, stream, indent, &opts, current_language);
+	  fputc_filtered ('\n', stream);
+	}
+      if (entryval)
+	{
+	  fprintf_filtered (stream, "%s%s@entry = ", n_spaces (2 * indent),
+			    name);
+	  common_val_print (entryval, stream, indent, &opts, current_language);
+	  fputc_filtered ('\n', stream);
+	}
     }
   if (except.reason < 0)
-    fprintf_filtered(stream, "<error reading variable %s (%s)>", name,
-		     except.message);
-  fprintf_filtered (stream, "\n");
+    fprintf_filtered (stream, "%s%s = <error reading variable %s (%s)>\n",
+		      n_spaces (2 * indent), name, name, except.message);
 }
 
 /* printf "printf format string" ARG to STREAM.  */
--- a/gdb/stack.c
+++ b/gdb/stack.c
@@ -1609,6 +1609,7 @@ struct print_variable_and_value_data
   int num_tabs;
   struct ui_file *stream;
   int values_printed;
+  enum print_argument print_argument;
 };
 
 /* The callback for the locals and args iterators.  */
@@ -1620,13 +1621,17 @@ do_print_variable_and_value (const char *print_name,
 {
   struct print_variable_and_value_data *p = cb_data;
 
-  print_variable_and_value (print_name, sym,
-			    p->frame, p->stream, p->num_tabs);
+  print_variable_and_value (print_name, sym, p->frame, p->stream, p->num_tabs,
+			    p->print_argument);
   p->values_printed = 1;
 }
 
+/* Show function local variables at FRAME.  FROM_FRAME is 1 if the local
+   variables are printed after the function frame (parameter values) have been
+   printed, it is 0 otherwise.  Print them to STREAM.  */
+
 static void
-print_frame_local_vars (struct frame_info *frame, int num_tabs,
+print_frame_local_vars (struct frame_info *frame, int from_frame,
 			struct ui_file *stream)
 {
   struct print_variable_and_value_data cb_data;
@@ -1648,10 +1653,24 @@ print_frame_local_vars (struct frame_info *frame, int num_tabs,
     }
 
   cb_data.frame = frame;
-  cb_data.num_tabs = 4 * num_tabs;
+  cb_data.num_tabs = from_frame ? 4 : 0;
   cb_data.stream = stream;
   cb_data.values_printed = 0;
 
+  if (from_frame)
+    {
+      /* For the variables we display them from the innermost block.  But for
+         parameters we need to fetch the outermost block still in the same
+         function.  Stop at the first inlined function boundary, if any.  */
+      struct symbol *func = get_frame_function (frame);
+
+      cb_data.print_argument = PVAVD_ARGUMENT_PRINT_ENTRYVAL_ONLY;
+      if (func)
+	iterate_over_block_arg_vars (SYMBOL_BLOCK_VALUE (func),
+				     do_print_variable_and_value, &cb_data);
+    }
+
+  cb_data.print_argument = PVAVD_IS_NOT_ARGUMENT;
   iterate_over_block_local_vars (block,
 				 do_print_variable_and_value,
 				 &cb_data);
@@ -1811,6 +1830,7 @@ print_frame_arg_vars (struct frame_info *frame, struct ui_file *stream)
   cb_data.stream = gdb_stdout;
   cb_data.values_printed = 0;
 
+  cb_data.print_argument = PVAVD_ARGUMENT_PRINT_BOTH;
   iterate_over_block_arg_vars (SYMBOL_BLOCK_VALUE (func),
 			       do_print_variable_and_value, &cb_data);
 
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -533,6 +533,12 @@ struct symbol_computed_ops
   struct value *(*read_variable) (struct symbol * symbol,
 				  struct frame_info * frame);
 
+  /* Read variable SYMBOL like read_variable at (callee) FRAME's function
+     entry.  SYMBOL should be a function parameter, otherwise NOT_FOUND_ERROR
+     will be thrown.  */
+  struct value *(*read_variable_at_entry) (struct symbol *symbol,
+					   struct frame_info *frame);
+
   /* Return non-zero if we need a frame to find the value of the SYMBOL.  */
   int (*read_needs_frame) (struct symbol * symbol);
 
--- a/gdb/testsuite/gdb.arch/amd64-entry-value.cc
+++ b/gdb/testsuite/gdb.arch/amd64-entry-value.cc
@@ -113,10 +113,37 @@ self (int i)
     }
 }
 
+static void __attribute__((noinline, noclone))
+stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1, int s2)
+{
+  s1 = 3;
+  s2 = 4;
+  e (v);
+asm ("breakhere_stacktest:");
+  e (v);
+}
+
+static void __attribute__((noinline, noclone))
+reference (int &refparam)
+{
+  int refcopy = refparam;
+
+  refparam = 10;
+asm ("breakhere_reference:");
+  e (v);
+}
+
 int
 main ()
 {
+  int refvar;
+
   d (30);
+  stacktest (1, 2, 3, 4, 5, 6, 11, 12);
+
+  refvar = 5;
+  reference (refvar);
+
   if (v)
     a (1);
   else
--- a/gdb/testsuite/gdb.arch/amd64-entry-value.exp
+++ b/gdb/testsuite/gdb.arch/amd64-entry-value.exp
@@ -35,6 +35,10 @@ if ![runto_main] {
 }
 
 gdb_breakpoint "breakhere"
+gdb_breakpoint "stacktest"
+gdb_breakpoint "breakhere_stacktest"
+gdb_breakpoint "reference"
+gdb_breakpoint "breakhere_reference"
 
 
 # Test @entry values for register passed parameters.
@@ -43,12 +47,68 @@ gdb_continue_to_breakpoint "entry: breakhere"
 
 # (gdb) bt full
 # #0  d (i=31) at gdb.arch/amd64-entry-value.cc:33
+#         i@entry = 30
 # #1  0x00000000004003da in main () at gdb.arch/amd64-entry-value.cc:56
-gdb_test "bt full" "^bt full\r\n#0 +d *\\(i=31\\) \[^\r\n\]*\r\nNo locals\\.\r\n#1 +0x\[0-9a-f\]+ in main .*" \
+gdb_test "bt full" "^bt full\r\n#0 +d *\\(i=31\\) \[^\r\n\]*\r\n\[ \t\]*i@entry = 30\r\n#1 +0x\[0-9a-f\]+ in main .*" \
 	 "entry: bt full"
 gdb_test "p i" " = 31" "entry: p i"
 
 
+# Test @entry values for stack passed parameters.
+
+gdb_continue_to_breakpoint "entry_stack: stacktest"
+
+# (gdb) bt full
+# #0  stacktest (r1=1, r2=2, r3=3, r4=4, r5=5, r6=6, s1=11, s2=12) at gdb.arch/amd64-entry-value.cc:121
+# #1  0x0000000000400412 in main () at gdb.arch/amd64-entry-value.cc:142
+# Check s1 and s2 are suppressed:
+gdb_test "bt full" "^bt full\r\n#0 +stacktest *\\(r1=1, r2=2, r3=3, r4=4, r5=5, r6=6, s1=11, s2=12\\) \[^\r\n\]*\r\n#1 +0x\[0-9a-f\]+ in main .*" \
+	 "entry_stack: bt full at entry"
+
+gdb_continue_to_breakpoint "entry_stack: breakhere_stacktest"
+
+# (gdb) bt full
+# #0  stacktest (r1=1, r2=2, r3=3, r4=4, r5=5, r6=6, s1=3, s2=4) at gdb.arch/amd64-entry-value.cc:123
+#         s1@entry = 11
+#         s2@entry = 12
+# #1  0x0000000000400412 in main () at gdb.arch/amd64-entry-value.cc:130
+# Check s1 and s2 are present:
+gdb_test "bt full" "^bt full\r\n#0 +stacktest *\\(r1=1, r2=2, r3=3, r4=4, r5=5, r6=6, s1=3, s2=4\\) \[^\r\n\]*\r\n\[ \t\]*s1@entry = 11\r\n\[ \t\]*s2@entry = 12\r\n#1 +0x\[0-9a-f\]+ in main .*" \
+	 "entry_stack: bt full"
+
+gdb_test "p s1" " = 3" "entry_stack: p s1"
+gdb_test "p s2" " = 4" "entry_stack: p s2"
+
+
+# Test @entry values for DW_AT_GNU_call_site_data_value parameters.
+
+gdb_continue_to_breakpoint "entry_reference: reference"
+
+# (gdb) bt full
+# #0  reference (refparam=@0x7fffffffdc3c) at gdb.arch/amd64-entry-value.cc:131
+#         refcopy = 5
+# #1  0x0000000000400424 in main () at gdb.arch/amd64-entry-value.cc:145
+#         refvar = 5
+# Check refparam@entry is suppressed:
+gdb_test "bt full" "#0 +reference \\(refparam=@0x\[0-9a-f\]+\\) \[^\r\n\]*\r\n\[ \t\]*refcopy = 5\r\n#1 +0x\[0-9a-f\]+ in main \\(\\) \[^\r\n\]*\r\n\[ \t\]*refvar = 5" \
+	 "entry_reference: bt full at entry"
+
+gdb_continue_to_breakpoint "entry_reference: breakhere_reference"
+
+# (gdb) bt full
+# #0  reference (refparam=@0x7fffffffdc3c) at gdb.arch/amd64-entry-value.cc:133
+#         refcopy = 5
+# #1  0x0000000000400424 in main () at gdb.arch/amd64-entry-value.cc:145
+#         refvar = 10
+# Check refparam@entry is present:
+gdb_test "bt full" "#0 +reference \\(refparam=@0x\[0-9a-f\]+\\) \[^\r\n\]*\r\n\[ \t\]*refcopy = 5\r\n#1 +0x\[0-9a-f\]+ in main \\(\\) \[^\r\n\]*\r\n\[ \t\]*refvar = 10" \
+	 "entry_reference: bt full"
+gdb_test "ptype refparam" " = int &" "entry_reference: ptype refparam"
+
+gdb_test "p refparam" { = \(int &\) @0x[0-9a-f]+: 10} "entry_reference: p refparam"
+gdb_test "p refcopy" " = 5" "entry_reference: p refcopy"
+
+
 # Test virtual tail call frames.
 
 gdb_continue_to_breakpoint "tailcall: breakhere"
--- a/gdb/value.h
+++ b/gdb/value.h
@@ -801,11 +801,28 @@ extern int val_print_string (struct type *elttype, const char *encoding,
 			     struct ui_file *stream,
 			     const struct value_print_options *options);
 
+/* Specify how the @entry kind of function parameters should be printed.  */
+enum print_argument
+{
+  /* Symbol is not a function parameter - it is a variable.  */
+  PVAVD_IS_NOT_ARGUMENT,
+
+  /* Symbol is a function parameter, print only its @entry value if it is not
+     redundant together with the normal symbol printed value.  */
+  PVAVD_ARGUMENT_PRINT_ENTRYVAL_ONLY,
+
+  /* Symbol is a function parameter, print its normal value.  Print also its
+     @entry value if it is not redundant together with its normal printed
+     value.  */
+  PVAVD_ARGUMENT_PRINT_BOTH
+};
+
 extern void print_variable_and_value (const char *name,
 				      struct symbol *var,
 				      struct frame_info *frame,
 				      struct ui_file *stream,
-				      int indent);
+				      int indent,
+				      enum print_argument print_argument);
 
 extern int check_field (struct type *, const char *);
 

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Daniel Jacobowitz]

On Mon, Jul 18, 2011 at 4:18 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> p@entry is not particularly useful here because the `line' local variable
> contains the same.  One can imagine in other real world applications it can be
> useful - for a backtrace sent by user where you do not have a reproducer and/or
> the core file (the case of ABRT bugreports).
>
> The parameter@entry lines are not displayed if they are not useful.  Therefore
> if they would display the same value as the current parameter value or if GDB
> cannot successfully determine the entry value.
>
> It is displayed by `bt full' and `info args'.  RFC is whether it is not too
> verbose and/or if it should not be displayed some way even with normal `bt'.
> Also whether there should be some `set' variable to forget about @entry values.

Thoughts:

* It is really frustrating when GDB knows the value of something, but
I can't access it as a variable.  That means I can't explore it as a
typed value without having to copy it, paste it, and add a cast to the
right pointer type.  There should be a way to get these values back.

* Any awesomely useful feature like this one should consider MI access
from the start.  How would you want to portray this data in an IDE?
How would you communicate it through MI to the IDE?

I am not in love with the @entry name, but maybe we can combine it
with the above... something like "$at_entry(p)" that could be
evaluated in an expression?  Better naming welcome.

-- 
Thanks,
Daniel

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Eli Zaretskii]

> Date: Mon, 18 Jul 2011 17:01:44 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.org
> 
> I am not in love with the @entry name, but maybe we can combine it
> with the above... something like "$at_entry(p)" that could be
> evaluated in an expression?  Better naming welcome.

Maybe I'm missing something important here (in fact, most probably I
am), but let me turn the table and ask: why do we need that @entry
qualifier at all?  Why not just show the name of the parameter itself
in the backtrace and let users evaluate `p' in expressions to mean
that value which GDB can recover under this series of patches?

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Jan Kratochvil]

On Tue, 19 Jul 2011 11:56:45 +0200, Eli Zaretskii wrote:
> Maybe I'm missing something important here (in fact, most probably I am), 

Yes.

> but let me turn the table and ask: why do we need that @entry
> qualifier at all?

The patchset would be useful for recovering the lost values without showing or
entering the @entry string anywhere, that is without having the entry values
explicitly user accessible at all.


> Why not just show the name of the parameter itself
> in the backtrace and let users evaluate `p' in expressions to mean
> that value which GDB can recover under this series of patches?

Yes, it works that way.


GDB internally knows the value of the parameter at the function entry - to be
able to recover the values.  It has been found out the developers may find it
useful to be shown the entry values it.  It is an additional feature on top of
the values recovery.

I think it is separated well enough in the patchset, up to incl. 05/12 it is
about values recovery, from 06/12 it is about user-accessible entry values.


Thanks,
Jan

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Eli Zaretskii]

> Date: Mon, 18 Jul 2011 22:18:53 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> this is a first kind of access to the entry values.  A (non-testcase) demo is:
> 
> #8  0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438
> 	p@entry = 0x22b5720 "maintenance internal-error "
> 	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 	arg = <optimized out>
> 	cleanup = 0x28333b0
> 	c = 0x24996d0
> 	flang = <optimized out>
> 	warned = 0
> 	line = 0x22b5720 "maintenance internal-error "
> 
> p@entry is not particularly useful here because the `line' local variable
> contains the same.  One can imagine in other real world applications it can be
> useful - for a backtrace sent by user where you do not have a reproducer and/or
> the core file (the case of ABRT bugreports).
> 
> The parameter@entry lines are not displayed if they are not useful.  Therefore
> if they would display the same value as the current parameter value or if GDB
> cannot successfully determine the entry value.
> 
> It is displayed by `bt full' and `info args'.  RFC is whether it is not too
> verbose and/or if it should not be displayed some way even with normal `bt'.
> Also whether there should be some `set' variable to forget about @entry values.

Thanks.

I'm not sure the DWIM-ish logic you describe is a good idea.  Why not
show the values at entry always, not just subject to the conditions
you described?  What will we lose?  And why should GDB second-guess
what the user will find "useful"?

Also, why display this just for "bt full"?  This feature will be very
important for analyzing crash tracebacks, and many such reports come
without "bt full", just with "bt".

See also my question about the @entry qualifier elsewhere in this
thread.

It's not clear from the docs whether the values at entry will be shown
only when they are passed in registers, or always.  The text sounds as
if it is always.

Otherwise, I have no comments for the documentation part.

Thanks.

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Eli Zaretskii]

> Date: Tue, 19 Jul 2011 12:30:55 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sourceware.org
> 
> GDB internally knows the value of the parameter at the function entry - to be
> able to recover the values.  It has been found out the developers may find it
> useful to be shown the entry values it.  It is an additional feature on top of
> the values recovery.

But then why don't we just show the value at entry in the function
call line?  IOW, show this:

  #8  0x000000000048c50d in execute_command (p=0x22b5720 "maintenance internal-error", from_tty=1) at top.c:438

instead of this:

  #8  0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438
	p@entry = 0x22b5720 "maintenance internal-error "

Also show those entry-time values in "info args", as you already
suggested.

This will also fix the annoyance I sometimes bump into, whereby if I
type "bt" some time after stepping into a function, the values of the
parameters are not necessarily those that were actual at the time of
the call (if the function modifies them).

> I think it is separated well enough in the patchset, up to incl. 05/12 it is
> about values recovery, from 06/12 it is about user-accessible entry values.

Sorry, I didn't read the code, only the doco parts and the general
discussion.

Thanks.

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Jakub Jelinek]

On Tue, Jul 19, 2011 at 07:14:04AM -0400, Eli Zaretskii wrote:
> > Date: Tue, 19 Jul 2011 12:30:55 +0200
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> > Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sourceware.org
> > 
> > GDB internally knows the value of the parameter at the function entry - to be
> > able to recover the values.  It has been found out the developers may find it
> > useful to be shown the entry values it.  It is an additional feature on top of
> > the values recovery.
> 
> But then why don't we just show the value at entry in the function
> call line?  IOW, show this:
> 
>   #8  0x000000000048c50d in execute_command (p=0x22b5720 "maintenance internal-error", from_tty=1) at top.c:438
> 
> instead of this:
> 
>   #8  0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438
> 	p@entry = 0x22b5720 "maintenance internal-error "
> 
> Also show those entry-time values in "info args", as you already
> suggested.

There are several possibilities of what info may be available for
a parameter:
1) the entry value as well as current value of the parameter are known
   and known to be equal
2) both entry value and current value of the parameter are known, but are
   different
3) only entry value is known, current value is optimized out
4) only current value is known, entry value isn't provided (the value
   passed to the function in the caller wasn't saved in any call saved
   register or memory slot and wasn't constant, or the compiler didn't
   provide call site info for it)
5) neither the entry value nor current value are known (both are
   optimized out)

It might be a good idea to give the user for backtraces the ability
to say his preference what kind of values he would like to see and what
information should be printed in all of the above cases, but in any
case if anything but the current value is printed in the backtrace, it
should be obvious what kind of value it is (some way to say that
it is both the current and entry value, aka case 1), some other way
to print both values if requested (case 2), if user wants to print
just one of the values it would be like 3) or 4) ), etc.

Jan's 01-05 patches are just for using the entry value in computation
of a current value (either when the compiler knows that somewhere
both values are the same, i.e. case 1), or when the current value
is based on an entry value (say entry_value + constant etc.), or
some variable or parameter's current value is based on entry value
of any of the parameters.

	Jakub

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> p@entry is not particularly useful here because the `line' local
Jan> variable contains the same.  One can imagine in other real world
Jan> applications it can be useful - for a backtrace sent by user where
Jan> you do not have a reproducer and/or the core file (the case of ABRT
Jan> bugreports).

Jan> The parameter@entry lines are not displayed if they are not useful.
Jan> Therefore if they would display the same value as the current
Jan> parameter value or if GDB cannot successfully determine the entry
Jan> value.

Jan> It is displayed by `bt full' and `info args'.  RFC is whether it is
Jan> not too verbose and/or if it should not be displayed some way even
Jan> with normal `bt'.  Also whether there should be some `set' variable
Jan> to forget about @entry values.

I think it is often confusing to users to see the currently value in a
backtrace.  Certainly this has confused me any number of times.

My first thought is to display this information by default in the
backtrace, even in the short form.

However, then I think there is another possible confusion -- some
arguments may have entry values, and some may not; and I think it would
be nice to clearly distinguish this for users.

How about something like:

#8  0x000000000048c50d in execute_command (p=0x22b573b "" (p@entry=0x22b5720 "maintenance internal-error "), from_tty=1) at top.c:438


Here, the entry value is clearly distinguished and arguments lacking an
entry value are also immediately visible.

If this is too verbose for somebody, let them complain and we can add a
new parameter.

If you think it is important to also distinguish the case where the
argument is equal to its entry value, then we can add additional output
sugar for that, e.g.:

#8  0x000000000048c50d in execute_command (p=p@entry=0x22b573b "whatever", from_tty=1) at top.c:438

Tom

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Eli Zaretskii]

> Date: Tue, 19 Jul 2011 13:41:48 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, drow@false.org,
>         gdb-patches@sourceware.org
> 
> > But then why don't we just show the value at entry in the function
> > call line?  IOW, show this:
> > 
> >   #8  0x000000000048c50d in execute_command (p=0x22b5720 "maintenance internal-error", from_tty=1) at top.c:438
> > 
> > instead of this:
> > 
> >   #8  0x000000000048c50d in execute_command (p=0x22b573b "", from_tty=1) at top.c:438
> > 	p@entry = 0x22b5720 "maintenance internal-error "
> > 
> > Also show those entry-time values in "info args", as you already
> > suggested.
> 
> There are several possibilities of what info may be available for
> a parameter:

Thanks, I understand all that, but I'm not sure I see how is this
relevant to the issue at hand.

> 1) the entry value as well as current value of the parameter are known
>    and known to be equal

This is trivial.

> 2) both entry value and current value of the parameter are known, but are
>    different

This is the case I was talking about.  Normally, "print foo" shows
the current value of `foo'.  The values in the function call currently
show the current values, but I think they should show the entry-time
values with this new feature.

> 3) only entry value is known, current value is optimized out

Show the entry value in the call and backtraces, say "optimized out"
in response to "print foo".

> 4) only current value is known, entry value isn't provided (the value
>    passed to the function in the caller wasn't saved in any call saved
>    register or memory slot and wasn't constant, or the compiler didn't
>    provide call site info for it)

Show "optimized out" in calls and backtraces, the current value in
response to "print foo".

> 5) neither the entry value nor current value are known (both are
>    optimized out)

Show "optimized out" for both; again, trivial.

> It might be a good idea to give the user for backtraces the ability
> to say his preference what kind of values he would like to see and what
> information should be printed in all of the above cases, but in any
> case if anything but the current value is printed in the backtrace, it
> should be obvious what kind of value it is (some way to say that
> it is both the current and entry value, aka case 1), some other way
> to print both values if requested (case 2), if user wants to print
> just one of the values it would be like 3) or 4) ), etc.

I'd rather we showed what we DTRT without asking the user to provide
too much guidance.

> Jan's 01-05 patches are just for using the entry value in computation
> of a current value (either when the compiler knows that somewhere
> both values are the same, i.e. case 1), or when the current value
> is based on an entry value (say entry_value + constant etc.), or
> some variable or parameter's current value is based on entry value
> of any of the parameters.

Understood.  I was talking about the second part.

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Jakub Jelinek]

On Tue, Jul 19, 2011 at 07:38:41PM +0300, Eli Zaretskii wrote:
> > 4) only current value is known, entry value isn't provided (the value
> >    passed to the function in the caller wasn't saved in any call saved
> >    register or memory slot and wasn't constant, or the compiler didn't
> >    provide call site info for it)
> 
> Show "optimized out" in calls and backtraces, the current value in
> response to "print foo".

This is IMHO a bad idea, the current value is still far better than
"optimized out", at least when it is obvious from the backtrace which one is
which.  All -O0 compiled code would show just "optimized out" in backtraces
for all arguments, similarly all code compiled by older compilers.
And, even for -O2 -g code the entry value will be available in roughly 50%
of cases at most.  The lack of entry value being provided doesn't mean
that the current value isn't the same as the value on entry, just that it
wasn't proved.

	Jakub

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Jan Kratochvil]

On Tue, 19 Jul 2011 13:41:48 +0200, Jakub Jelinek wrote:
> There are several possibilities of what info may be available for
> a parameter:

> 1) the entry value as well as current value of the parameter are known
>    and known to be equal
="equal"

> 2) both entry value and current value of the parameter are known, but are
>    different
="different" variable "i" (or variable "j")

> 3) only entry value is known, current value is optimized out
="validity" parameter "lost"

> 4) only current value is known, entry value isn't provided (the value
>    passed to the function in the caller wasn't saved in any call saved
>    register or memory slot and wasn't constant, or the compiler didn't
>    provide call site info for it)
="validity" parameter "born"

> 5) neither the entry value nor current value are known (both are
>    optimized out)
="invalid"

> It might be a good idea to give the user for backtraces the ability
> to say his preference what kind of values he would like to see and what
> information should be printed in all of the above cases,

Such full configurability would have about 5 GDB `set' variables and it would
not be convenient to choose the practical possibilities from all of those.
Most of its combinations would not make sense.  If there is an idea for
a useful new behavior GDB can be easily extended for it.

Is there an agreement upon the output below?  `set print entry-values both'
shows the real program state.  `set print entry-values compact' should be the
default option.  `set print entry-values preferred' may be possibly the choice
for some backtraces.  I would like an approval before I rebuild the testfile
with it again.

The output possibilities are currently limited by the fact that there is no
reliable possibility to distinguish CU (Compilation Unit) which was compiled
without entry-values support (old gcc -g or new gcc -O0 -g; remember only new
gcc -O -g produces entry-values) vs. CU in which there was no valid info to
create at least one DW_TAG_GNU_call_site with.  The default settings must
therefore suppress any @entry values output for -O0 -g CUs - it would be very
inconvenient to start printing p=1, p@entry=<optimized out> for all the
parameters in -O0 -g CUs.  Whether GDB could differentiate such old CU vs. new
CU with all call sites <optimized out> is a different question, Jakub did not
recommend to differentiate it.

(For MI there proposing a new separate list "args_entry" besides the current
"args" list so there is nothing to talk about, it always acts as "set print
entry-values both", it can be reviewed later in the patch.)


Thanks,
Jan


set print entry-values no
Print only actual parameter values, never print values from function entry
point.

different
#0  d (i=31, j=31.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values only
Print only values from function entry point.  The actual parameter values
are never printed.

different
#0  d (i@entry=30, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i@entry=<optimized out>, j@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values preferred
Print only values from function entry point.  If value from function entry
point is not known while the actual value is known print at least the actual
value for such parameter.

different
#0  d (i@entry=30, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values both
Always print both the actual parameter value and its value from function entry
point.  Still print both even if one of them or both are <optimized out>.

different
#0  d (i=31, i@entry=30, j=31.5, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, lost@entry=5, born=10, born@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, i@entry=<optimized out>, j=<optimized out>, j@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=100, i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values compact
Always print the actual parameter value.  Print also its value from function
entry point but only if it is known.  If both values are known and they are
equal print the shortened param=param@entry=VALUE notation.

different
#0  d (i=31, i@entry=30, j=31.5, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Jan Kratochvil]

Extended by `set print entry-values if-needed' as suggested (not its name)
by Jakub.


On Wed, 03 Aug 2011 19:27:25 +0200, Jan Kratochvil wrote:

On Tue, 19 Jul 2011 13:41:48 +0200, Jakub Jelinek wrote:
> There are several possibilities of what info may be available for
> a parameter:

> 1) the entry value as well as current value of the parameter are known
>    and known to be equal
="equal"

> 2) both entry value and current value of the parameter are known, but are
>    different
="different" variable "i" (or variable "j")

> 3) only entry value is known, current value is optimized out
="validity" parameter "lost"

> 4) only current value is known, entry value isn't provided (the value
>    passed to the function in the caller wasn't saved in any call saved
>    register or memory slot and wasn't constant, or the compiler didn't
>    provide call site info for it)
="validity" parameter "born"

> 5) neither the entry value nor current value are known (both are
>    optimized out)
="invalid"

> It might be a good idea to give the user for backtraces the ability
> to say his preference what kind of values he would like to see and what
> information should be printed in all of the above cases,

Such full configurability would have about 5 GDB `set' variables and it would
not be convenient to choose the practical possibilities from all of those.
Most of its combinations would not make sense.  If there is an idea for
a useful new behavior GDB can be easily extended for it.

Is there an agreement upon the output below?  `set print entry-values both'
shows the real program state.  `set print entry-values compact' should be the
default option.  `set print entry-values preferred' may be possibly the choice
for some backtraces.  I would like an approval before I rebuild the testfile
with it again.

The output possibilities are currently limited by the fact that there is no
reliable possibility to distinguish CU (Compilation Unit) which was compiled
without entry-values support (old gcc -g or new gcc -O0 -g; remember only new
gcc -O -g produces entry-values) vs. CU in which there was no valid info to
create at least one DW_TAG_GNU_call_site with.  The default settings must
therefore suppress any @entry values output for -O0 -g CUs - it would be very
inconvenient to start printing p=1, p@entry=<optimized out> for all the
parameters in -O0 -g CUs.  Whether GDB could differentiate such old CU vs. new
CU with all call sites <optimized out> is a different question, Jakub did not
recommend to differentiate it.

(For MI there proposing a new separate list "args_entry" besides the current
"args" list so there is nothing to talk about, it always acts as "set print
entry-values both", it can be reviewed later in the patch.)


Thanks,
Jan


set print entry-values no
Print only actual parameter values, never print values from function entry
point.

different
#0  d (i=31, j=31.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values only
Print only parameter values from function entry point.  The actual parameter
values are never printed.

different
#0  d (i@entry=30, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i@entry=<optimized out>, j@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values preferred
Print only parameter values from function entry point.  If value from function
entry point is not known while the actual value is known print at least the
actual value for such parameter.

different
#0  d (i@entry=30, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values if-needed
Print actual parameter values.  If actual parameter value is not known while
value from function entry point is known print at least the entry point value
for such parameter.

different
#0  d (i=31, j=31.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values both
Always print both the actual parameter value and its value from function entry
point.  Still print both even if one of them or both are <optimized out>.

different
#0  d (i=31, i@entry=30, j=31.5, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, lost@entry=5, born=10, born@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, i@entry=<optimized out>, j=<optimized out>, j@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=100, i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values compact
Always print the actual parameter value.  Print also its value from function
entry point but only if it is known.  If both values are known and they are
equal print the shortened param=param@entry=VALUE notation.

different
#0  d (i=31, i@entry=30, j=31.5, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Jan Kratochvil]

Extended by `set print entry-values default' (which is more backward
compatible) vs. the changed `compact' output as suggested by Jakub.

On Wed, 03 Aug 2011 19:53:29 +0200, Jan Kratochvil wrote:

Extended by `set print entry-values if-needed' as suggested (not its name)
by Jakub.

On Wed, 03 Aug 2011 19:27:25 +0200, Jan Kratochvil wrote:

On Tue, 19 Jul 2011 13:41:48 +0200, Jakub Jelinek wrote:
> There are several possibilities of what info may be available for
> a parameter:

> 1) the entry value as well as current value of the parameter are known
>    and known to be equal
="equal"

> 2) both entry value and current value of the parameter are known, but are
>    different
="different" variable "i" (or variable "j")

> 3) only entry value is known, current value is optimized out
="validity" parameter "lost"

> 4) only current value is known, entry value isn't provided (the value
>    passed to the function in the caller wasn't saved in any call saved
>    register or memory slot and wasn't constant, or the compiler didn't
>    provide call site info for it)
="validity" parameter "born"

> 5) neither the entry value nor current value are known (both are
>    optimized out)
="invalid"

> It might be a good idea to give the user for backtraces the ability
> to say his preference what kind of values he would like to see and what
> information should be printed in all of the above cases,

Such full configurability would have about 5 GDB `set' variables and it would
not be convenient to choose the practical possibilities from all of those.
Most of its combinations would not make sense.  If there is an idea for
a useful new behavior GDB can be easily extended for it.

Is there an agreement upon the output below?  `set print entry-values both'
shows the real program state.  `set print entry-values default' should be the
default option.  `set print entry-values preferred' may be possibly the choice
for some backtraces.  I would like an approval before I rebuild the testfile
with it again.

The output possibilities are currently limited by the fact that there is no
reliable possibility to distinguish CU (Compilation Unit) which was compiled
without entry-values support (old gcc -g or new gcc -O0 -g; remember only new
gcc -O -g produces entry-values) vs. CU in which there was no valid info to
create at least one DW_TAG_GNU_call_site with.  The default settings must
therefore suppress any @entry values output for -O0 -g CUs - it would be very
inconvenient to start printing p=1, p@entry=<optimized out> for all the
parameters in -O0 -g CUs.  Whether GDB could differentiate such old CU vs. new
CU with all call sites <optimized out> is a different question, Jakub did not
recommend to differentiate it.

(For MI there proposing a new separate list "args_entry" besides the current
"args" list so there is nothing to talk about, it always acts as "set print
entry-values both", it can be reviewed later in the patch.)


Thanks,
Jan


set print entry-values no
Print only actual parameter values, never print values from function entry
point.

different
#0  d (i=31, j=31.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values only
Print only parameter values from function entry point.  The actual parameter
values are never printed.

different
#0  d (i@entry=30, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i@entry=<optimized out>, j@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values preferred
Print only parameter values from function entry point.  If value from function
entry point is not known while the actual value is known print at least the
actual value for such parameter.

different
#0  d (i@entry=30, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values if-needed
Print actual parameter values.  If actual parameter value is not known while
value from function entry point is known print at least the entry point value
for such parameter.

different
#0  d (i=31, j=31.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values both
Always print both the actual parameter value and its value from function entry
point.  Still print both even if one of them or both are <optimized out>.

different
#0  d (i=31, i@entry=30, j=31.5, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, lost@entry=5, born=10, born@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, i@entry=<optimized out>, j=<optimized out>, j@entry=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=100, i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values compact
Print the actual parameter value if it is know and also its value from
function entry point if it is known.  If neither is known print for the actual
value <optimized out>.  If both values are known and they are equal print the
shortened param=param@entry=VALUE notation.

different
#0  d (i=31, i@entry=30, j=31.5, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98


set print entry-values default
Always print the actual parameter value.  Print also its value from function
entry point but only if it is known.  If both values are known and they are
equal print the shortened param=param@entry=VALUE notation.

different
#0  d (i=31, i@entry=30, j=31.5, j@entry=30.5) at ./gdb.arch/amd64-entry-value.cc:34
validity
#0  validity (lost=<optimized out>, lost@entry=5, born=10) at ./gdb.arch/amd64-entry-value.cc:166
invalid
#0  d (i=<optimized out>, j=<optimized out>) at ./gdb.arch/amd64-entry-value.cc:34
equal
#5  0x00000000004006f5 in amb_a (i=i@entry=100) at ./gdb.arch/amd64-entry-value.cc:98

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Tom Tromey]

Jan> Is there an agreement upon the output below?

I think it is very good.

Tom

Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Jan Kratochvil]

On Mon, 18 Jul 2011 23:01:44 +0200, Daniel Jacobowitz wrote:
> * It is really frustrating when GDB knows the value of something, but
> I can't access it as a variable.  That means I can't explore it as a
> typed value without having to copy it, paste it, and add a cast to the
> right pointer type.  There should be a way to get these values back.

This was addressed by:
	[RFC 11/12] entryval: "@entry" in input expressions


> * Any awesomely useful feature like this one should consider MI access
> from the start.  How would you want to portray this data in an IDE?
> How would you communicate it through MI to the IDE?

Frontend can ask for the paramname@entry symbols for each paramname.
I will include in the next patchset post "args_entry" MI frame list.

I am aware of various further extensions of this patchset but I wanted to get
some first useful part into FSF GDB after a year of off-trunk development.
I have not considered the MI interface would affect the design of this first
part (sure I may be wrong).


> I am not in love with the @entry name, but maybe we can combine it
> with the above... something like "$at_entry(p)" that could be
> evaluated in an expression?  Better naming welcome.

There were no other complaints to the `parametername@entry' naming and I find
it personally more user acceptable than `$at_entry(parametername)'.
`parametername@entry' is evaluable in an expression, the patch:
	[RFC 11/12] entryval: "@entry" in input expressions

SystemTap is already using `@entry(expression)' syntax but that exists for
general expressions and it is not based on this DWARF extension (it will
quietly stop+continue at the function entry point for it - like GDB trace).


Thanks,
Jan

[MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full]

[Jan Kratochvil]

Hi Volodya,

intro:
	[patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames
	http://sourceware.org/ml/gdb-patches/2011-07/msg00430.html
currently implemented at:
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
	archer-jankratochvil-entryval

asking here how the MI format should look like.


The CLI part prints (in default `set print entry-values default'):
Breakpoint 8, validity (lost=<optimized out>, lost@entry=5, born=10) at gdb.arch/amd64-entry-value.cc:200

(1)
so I am inclined to just produce these MI records (which normal and @entry
variable variants get included depends on `-gdb-set print entry-values' like in
CLI):
print_frame_args:
	*stopped,[...],args=[{name="lost",value="<optimized out>"},{name="lost@entry",value="5"},{name="born",value="10"}],[...]
list_args_or_locals:
	-stack-list-variables --all-values
	^done,variables=[{name="lost",arg="1",value="<optimized out>"},{name="lost@entry",arg="1",value="5"},{name="born",arg="1",value="10"}]

(2)
currently the archer-jankratochvil-entryval branch implements this variant:
*stopped,[...],args=[{name="lost",value="<optimized out>",entry_value="5"},{name="born",value="10"}],[...]
-stack-list-variables --all-values
^done,variables=[{name="lost",arg="1",value="<optimized out>",entry_value="5"},{name="born",arg="1",value="10"}]
with .exp samples in:
	http://sourceware.org/git/gitweb.cgi?p=archer.git;a=blob_plain;f=gdb/testsuite/gdb.mi/mi2-amd64-entry-value.exp;hb=archer-jankratochvil-entryval

(3)
and I have some older implementation saved which produced:
*stopped,[...],args=[{name="lost",value="<optimized out>"},{name="born",value="10"}],args_entry=[{name="lost",value="5"}],[...]
although the list_args_or_locals mode not sure how it should look like.

(4)
?


The paramname@entry variant (1) requires no extra FE (Front End) extensions,
it should also be fully backward compatible.  The paramname@entry variables are
special that one cannot modify them but that is true also for other variables.

For (2) and (3) for FEs with proper parser an additional result should be
ignored correctly.  For FEs with some ugly manual matching I also do not think
it should be a problem as FEs are usually used for -O0 -g code debugging while
entry values are present only in -O2 -g code.  System libraries would be more a
problem although those on many OSes do not have the -g part.

For the FE->GDB part the FE can normally use `paramname@entry' strings instead
of `paramname' in expression strings as shown in [2].
	[2] http://people.redhat.com/jkratoch/eclipse2.png

The (2) case I tested with eclipse-cdt-8.0.0-5.fc16.x86_64 and ignores the
`entry_value' part correctly.  Maybe it could add the `entry value' in details
of the `val' parameter - as shown in the [1] picture (for that case maybe the
(2) format is better but sure FE is able to use any of the MI formats).
	[1] http://people.redhat.com/jkratoch/eclipse1.png


Thanks for advice,
Jan

Re: [MI RFC] entryval: MI access to entry values

[Jan Kratochvil]

On Fri, 02 Sep 2011 19:07:45 +0200, Jan Kratochvil wrote:
> (1)
> so I am inclined to just produce these MI records (which normal and @entry
> variable variants get included depends on `-gdb-set print entry-values' like in
> CLI):
> print_frame_args:
> 	*stopped,[...],args=[{name="lost",value="<optimized out>"},{name="lost@entry",value="5"},{name="born",value="10"}],[...]
> list_args_or_locals:
> 	-stack-list-variables --all-values
> 	^done,variables=[{name="lost",arg="1",value="<optimized out>"},{name="lost@entry",arg="1",value="5"},{name="born",arg="1",value="10"}]

FYI chosen this variant in:
	[patch 07/12+doc] entryval#2: Display @entry parameters
	http://sourceware.org/ml/gdb-patches/2011-09/msg00229.html


Jan

Re: [MI RFC] entryval: MI access to entry values

[Vladimir Prus]

On Tuesday, September 13, 2011 23:54:23 Jan Kratochvil wrote:
> On Fri, 02 Sep 2011 19:07:45 +0200, Jan Kratochvil wrote:
> > (1)
> > so I am inclined to just produce these MI records (which normal and
> > @entry variable variants get included depends on `-gdb-set print
> > entry-values' like in CLI):
> > 
> > print_frame_args:
> > 	*stopped,[...],args=[{name="lost",value="<optimized
> > 	out>"},{name="lost@entry",value="5"},{name="born",value="10"}],[...]
> > 
> > list_args_or_locals:
> > 	-stack-list-variables --all-values
> > 	^done,variables=[{name="lost",arg="1",value="<optimized
> > 	out>"},{name="lost@entry",arg="1",value="5"},{name="born",arg="1",value
> > 	="10"}]
> 
> FYI chosen this variant in:
> 	[patch 07/12+doc] entryval#2: Display @entry parameters
> 	http://sourceware.org/ml/gdb-patches/2011-09/msg00229.html

Sorry for not responding earlier. This approach certianly looks best for existing frontneds.

Thanks,

-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
+7 (812) 677-68-40

Re: [MI RFC] entryval: MI access to entry values

[André Pönitz]

On Wednesday 14 September 2011 09:17:42 ext Vladimir Prus wrote:
> On Tuesday, September 13, 2011 23:54:23 Jan Kratochvil wrote:
> > On Fri, 02 Sep 2011 19:07:45 +0200, Jan Kratochvil wrote:
> > > (1)
> > > so I am inclined to just produce these MI records (which normal and
> > > @entry variable variants get included depends on `-gdb-set print
> > > entry-values' like in CLI):
> > > 
> > > print_frame_args:
> > > 	*stopped,[...],args=[{name="lost",value="<optimized
> > > 	out>"},{name="lost@entry",value="5"},{name="born",value="10"}],[...]
> > > 
> > > list_args_or_locals:
> > > 	-stack-list-variables --all-values
> > > 	^done,variables=[{name="lost",arg="1",value="<optimized
> > > 	out>"},{name="lost@entry",arg="1",value="5"},{name="born",arg="1",value
> > > 	="10"}]
> > 
> > FYI chosen this variant in:
> > 	[patch 07/12+doc] entryval#2: Display @entry parameters
> > 	http://sourceware.org/ml/gdb-patches/2011-09/msg00229.html
> 
> Sorry for not responding earlier. This approach certianly looks best for existing frontneds.

In that generality I am afraid I disagree. MI has the ability to transfer data
in a structured way, there's no reason to pass the "@entry" marker in-channel
in the "name" field, and there's no reason to assume that a frontend would
want to present the entry value to the user as a "normal" value, just with a 
fancy name.

This is certainly an acceptable way to do it, but why should that needlessly
be steered by gdb?

From my point of view, something like 

   ^done,variables=[{name="lost",arg="1",value="<optimized out>",
        atentry="5"},{name="born",arg="1",value="10"}]

would be more in the "spirit" of MI, leaving the question of whether this
should be presented as one entry, as two, with mangled names or without,
with some attempt at localizing the "entry" string or without to the frontend.

Having said that, the proposed output would work, too, and as long as the
mangling is deterministic, a frontend can certainly undo it without much effort.

Andre'

Re: [MI RFC] entryval: MI access to entry values

[Jan Kratochvil]

On Wed, 14 Sep 2011 10:49:51 +0200, André Pönitz wrote:
> In that generality I am afraid I disagree. MI has the ability to transfer data
> in a structured way, there's no reason to pass the "@entry" marker in-channel
> in the "name" field, and there's no reason to assume that a frontend would
> want to present the entry value to the user as a "normal" value, just with a 
> fancy name.
> 
> This is certainly an acceptable way to do it, but why should that needlessly
> be steered by gdb?
> 
> From my point of view, something like 
> 
>    ^done,variables=[{name="lost",arg="1",value="<optimized out>",
>         atentry="5"},{name="born",arg="1",value="10"}]

"atentry" looks exactly like my "entry_value" proposed as variant (2) in (and
implemented in a local patch branch):
	[MI RFC] entryval: MI access to entry values
	http://sourceware.org/ml/gdb-patches/2011-09/msg00036.html


> would be more in the "spirit" of MI,

The problem is the "spirit" of MI is not there.  There should be already
instead of:
	{name="lost",arg="1",value="<optimized out>"}
rather:
	{name="lost",arg="1",optimized_out="1"}
and for value retrieval error messages
	../gdb -nx -i=mi gdb.dwarf2/dw2-param-error
	-break-insert f
	-exec-run
	*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x00000000004004b8",func="f",args=[{name="bad",value="<error reading variable: Asked for position 0 of stack, stack only has 0 elements on it.>"},{name="good",value="23"}]},thread-id="1",stopped-threads="all",core="4"
instead of (the current FSF GDB state):
	{name="bad",value="<error reading variable: Asked for position 0 of stack, stack only has 0 elements on it.>"}
there should be rather:
	{name="bad",error="<error reading variable: Asked for position 0 of stack, stack only has 0 elements on it.>"}
(this reproducing testcase is by me but this MI behavior existed there a long
time before)

So exactly in this spirit I chose rather more the front ends simplicity than
hypothetical MI protocol ideals.

But sure I would rather follow the design goals of the MI maintainer.


> Having said that, the proposed output would work, too, and as long as the
> mangling is deterministic, a frontend can certainly undo it without much effort.

There is already the @entry suffix used in input expressions so it cannot be
non-deterministic anyway.  At least for C/C++ @entry is not ambigous, neither
for Fortran, not sure about all the other languages.


Thanks,
Jan

Re: [MI RFC] entryval: MI access to entry values

[André Pönitz]

On Wednesday 14 September 2011 11:12:33 ext Jan Kratochvil wrote:
> On Wed, 14 Sep 2011 10:49:51 +0200, André Pönitz wrote:
> > In that generality I am afraid I disagree. MI has the ability to transfer data
> > in a structured way, there's no reason to pass the "@entry" marker in-channel
> > in the "name" field, and there's no reason to assume that a frontend would
> > want to present the entry value to the user as a "normal" value, just with a 
> > fancy name.
> > 
> > This is certainly an acceptable way to do it, but why should that needlessly
> > be steered by gdb?
> > 
> > From my point of view, something like 
> > 
> >    ^done,variables=[{name="lost",arg="1",value="<optimized out>",
> >         atentry="5"},{name="born",arg="1",value="10"}]
> 
> "atentry" looks exactly like my "entry_value" proposed as variant (2) in (and
> implemented in a local patch branch):
> 	[MI RFC] entryval: MI access to entry values
> 	http://sourceware.org/ml/gdb-patches/2011-09/msg00036.html
> 
> 
> > would be more in the "spirit" of MI,
> 
> The problem is the "spirit" of MI is not there.  

I was assuming it at least partially was, and when there are two possible
ways to add new stuff, there could be a bias to the one that's more
"in the spirit".

> There should be already instead of:
> 	{name="lost",arg="1",value="<optimized out>"}
> rather:
> 	{name="lost",arg="1",optimized_out="1"}

That's actually what I'd prefer, too. No magic in-channel strings that need
to be recognized and handled/translated separately, but different kinds
of data transferred in different channels.

I actually had already a stanza like that in the previous mail but removed
it before sending, as I did not want to trigger a compatibilty discussion.

> and for value retrieval error messages
> 	../gdb -nx -i=mi gdb.dwarf2/dw2-param-error
> 	-break-insert f
> 	-exec-run
> 	*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",
> time before)
> 
> So exactly in this spirit I chose rather more the front ends simplicity than
> hypothetical MI protocol ideals.

After giving some more thought I guess you and Volodya are indeed right.

Adding new ad-hoc data mangling is probably really the best for all existing 
frontends. For the "we just dump gdb output into a treeview"-kind of FE using 
whatever looks ok on the commandline is fine in the view, and the few others 
have to massage the output anyway. Adding yet another five lines of code to
recognize and modify the new entries is certainly less effort for the respective
maintainers than pondering the spiritual dimension of a protocol first.

 > But sure I would rather follow the design goals of the MI maintainer.

Absolutely.

Regards,
Andre'

Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full]

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> For (2) and (3) for FEs with proper parser an additional result
Jan> should be ignored correctly.  For FEs with some ugly manual
Jan> matching I also do not think it should be a problem as FEs are
Jan> usually used for -O0 -g code debugging while entry values are
Jan> present only in -O2 -g code.

For the record, I think we should not concern ourselves at all with such
MI consumers, if any exist.  MI has flaws, but this isn't among them; we
should expect consumers to reliably ignore new fields.

Tom

Re: [MI RFC] entryval: MI access to entry values

[Tom Tromey]

>>>>> "André" == André Pönitz <andre.poenitz@nokia.com> writes:

Jan> There should be already instead of:
Jan> {name="lost",arg="1",value="<optimized out>"}
Jan> rather:
Jan> {name="lost",arg="1",optimized_out="1"}

André> That's actually what I'd prefer, too. No magic in-channel strings
André> that need to be recognized and handled/translated separately, but
André> different kinds of data transferred in different channels.

FWIW this makes sense to me as well.

Can you file bugs for the cases you know about?  At least for this one I
think we could handle it in a backward-compatible way.

One possible issue is that the errors gdb can see are open-ended, but
presumably this could be dealt with sensibly by proper documentation.

Tom

Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full]

[Vladimir Prus]

On Monday, October 03, 2011 20:57:01 Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Jan> For (2) and (3) for FEs with proper parser an additional result
> Jan> should be ignored correctly.  For FEs with some ugly manual
> Jan> matching I also do not think it should be a problem as FEs are
> Jan> usually used for -O0 -g code debugging while entry values are
> Jan> present only in -O2 -g code.
> 
> For the record, I think we should not concern ourselves at all with such
> MI consumers, if any exist.  MI has flaws, but this isn't among them; we
> should expect consumers to reliably ignore new fields.

I presume the question is how important those those @entry values. If this
is something that would cause user a big grief if not shown, we might just
show them in format consistent with current frontends. If that's something
nice, but not essential, than maybe 2/3 are better options.


-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
+7 (812) 677-68-40

Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full]

[Jan Kratochvil]

On Mon, 03 Oct 2011 19:05:17 +0200, Vladimir Prus wrote:
> I presume the question is how important those those @entry values. If this
> is something that would cause user a big grief if not shown, we might just
> show them in format consistent with current frontends. If that's something
> nice, but not essential, than maybe 2/3 are better options.

I would like to restate that primarily I do not know a case when @entry values
are relevant for FEs and therefore for MI.  FEs typically rebuild the inferior
for debugging with -O0 -g and therefore @entry values are not present at all.

Maybe one can use Nemiver to investigate some deployed application crash and
in such case I find @entry values important.


Regards,
Jan

Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full]

[Joel Brobecker]

> I would like to restate that primarily I do not know a case when
> @entry values are relevant for FEs and therefore for MI.  FEs
> typically rebuild the inferior for debugging with -O0 -g and therefore
> @entry values are not present at all.

I know of at least a couple of projects where they debug their
optimized build routinely. The fact that they use a FE or not
is not relevant in their case.

-- 
Joel

Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full]

[André Pönitz]

On Monday 03 October 2011 19:43:20 ext Jan Kratochvil wrote:
> On Mon, 03 Oct 2011 19:05:17 +0200, Vladimir Prus wrote:
> > I presume the question is how important those those @entry values. If this
> > is something that would cause user a big grief if not shown, we might just
> > show them in format consistent with current frontends. If that's something
> > nice, but not essential, than maybe 2/3 are better options.
> 
> I would like to restate that primarily I do not know a case when @entry values
> are relevant for FEs and therefore for MI. FEs typically rebuild the inferior
> for debugging with -O0 -g  and therefore @entry values are not present at all.

At least in "my" case libraries loaded by the inferior are often compiled 
with -O2 -g, and stepping through that code is regularly done by users.

I still think it would have been nice to have a clean separation of the data
into individual "channels" on the gdb side, especially because this is new
functionality, but then, that's easily done on the FE side, too.

In any case, thank you for implementing the feature. It's much appreciated.

Andre'