Re: [patch 10/12] entryval: @entry values even for references

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 18 Jul 2011 23:04:06 +0200, Daniel Jacobowitz wrote:
> On Mon, Jul 18, 2011 at 4:22 PM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> > for parameters passed by reference the parameter itself does not change; only
> > the referenced (pointed to) value changes.  This would not be caught at all.
> 
> This is a little off topic from the current patch, but if the
> reference value is not known, and the reference entry value is known,
> should we use the entry value automatically?  Since it's supposed to
> be read-only.  This could potentially hide a corrupted reference
> pointer, that's the only downside.

IIUC added there:
+  /* Check if DW_AT_GNU_call_site_data_value cannot be used.  If it should be
+     used and it is not available do not fall back to OUTER_VAL - dereferencing
+     TYPE_CODE_REF with non-entry data value would give current value - not the
+     entry value.  */

That is if DW_AT_GNU_call_site_data_value could be used and it is not there do
cancel any call site computation at all.

+gdb_test "p nodataparam@entry" "Cannot resolve DW_AT_GNU_call_site_data_value" "entry_reference: p nodataparam@entry"

This works for TYPE_CODE_REF.  But still for some:
	(gdb) print glib_hash_pointer@entry
a pretty printer gets into effect which will print the current data values
referenced by the (unchanged) @entry pointer; this issue is not solved.


It will be in a new patchset resubmit.


Thanks,
Jan