This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: store.exp failure on i686-linux with newer gcc's


>>>>> "Nathan" == Nathan Froyd <froydnj@codesourcery.com> writes:

Nathan> If it does, maybe somebody will be so kind as to approve it in this
Nathan> thread rather than waiting for a resubmit. :)

Nice patch.

This conflicts with the DW_OP_*_value patch, but I looked and for the
most part it does not seem to be too hard to reconcile them.

Nathan> +static void
Nathan> +write_pieced_value (struct value *to, struct value *from)
Nathan> +{
[...]
Nathan> +  struct frame_info *frame = frame_find_by_id (VALUE_FRAME_ID (to));
Nathan> +
Nathan> +  if (frame == NULL)
Nathan> +    {
Nathan> +      set_value_optimized_out (to, 1);

What impact does this have on the error messages the user sees?
I didn't try to trace through the code; will setting a variable in this
scenario give an error?  (Or silently do nothing?)

Second, this seems like a change in behavior for the value history.
Suppose the user does "print local", which uses this machinery.
Then the inferior exits.  Then the user does "print $1" or whatever...
this ought to print the same value, but now I think the user will get an
error.  So, perhaps it is better to continue to copy in the bits
eagerly instead of postponing them to read_pieced_value.

Nathan> +  struct piece_closure *c = (struct piece_closure *) value_computed_closure (v);

I wish the closure were just passed as an argument to all these
callbacks, but that is just a drive-by complaint, not your problem.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]