This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 10/12] entryval: @entry values even for references
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