This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/3] New function value_has_address
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Pedro Alves <palves at redhat dot com>, Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org
- Date: Wed, 23 Nov 2016 09:26:21 +0000
- Subject: Re: [PATCH 1/3] New function value_has_address
- Authentication-results: sourceware.org; auth=none
- References: <bedd2d39-f72b-f4a5-82f1-d50099cbb5d7@redhat.com> <20161122181616.118F810B923@oc8523832656.ibm.com>
On Tue, Nov 22, 2016 at 07:16:15PM +0100, Ulrich Weigand wrote:
> > I think that it's good that the names match. If one is renamed,
> > so should the other, IMO. Maybe call the function
> > value_has_address_location? I think it'd be good if the
> > function's intro comment made this link more explicit.
> > Actually, I see now that patch #3 tweaks the comment.
>
> I think part of the confusion is that the comment above is simply
> no longer true; for lval_register values, address is *not* (any longer)
> used to hold any byte offset into a register structure, as far as I
> can see. Instead, for lval_register values, the register that holds
> the value is identifed solely via the VALUE_REGNUM/VALUE_NEXT_FRAME_ID
> fields, and the address field is ignored.
That is what I am saying in the last paragraph of cover letter.
>
> I think we should reword the comments to reflect the fact that
> "address" is only used for lval_address. On the other hand,
> the regnum/frame_id fields should move into the union and only
> be used for lval_register values ...
>
That is what I am trying to do in next step. Let me finish it and
include it in this series as well.
--
Yao (齐尧)