This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Don't allow setting register in non-innermost frame
- From: Tom Tromey <tromey at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Doug Evans <dje at google dot com>, <gdb-patches at sourceware dot org>
- Date: Tue, 11 Sep 2012 11:12:31 -0600
- Subject: Re: [RFC] Don't allow setting register in non-innermost frame
- References: <1345170040-25959-1-git-send-email-yao@codesourcery.com> <CADPb22SGp-9TaoA3rNi_PJordCuv_bjwFQZiHvfjktHx3Y_krA@mail.gmail.com> <87hartpodt.fsf@fleche.redhat.com> <20120907164544.GA18234@host2.jankratochvil.net> <504D49DA.6070006@codesourcery.com>
>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:
Yao> I checked the difference of value of register and value of variable
Yao> (saved in register), TYPE_OBJFILE_OWNED (value_type (toval)) is the
Yao> only difference between them. IIUC, type of variable is owned by an
Yao> objfile, while type of register is not (alloc_type vs. alloc_type_arch),
Yao> so looks we can use it to differentiate values in register and values
Yao> in variables.
I would rather not use this approach.
My reason is that there is no obvious connection between
TYPE_OBJFILE_OWNED and register-ness -- and it is the sort of invariant
that is very difficult to ensure will remain true over time.
If lval_register can't work, then another choice would be a new flag on
struct value. This would be somewhat ugly but, I think, more robust.
As Jan points out, it does seem strange to warn about the set rather
than query. A warning comes too late.
After re-reading the whole thread I wonder whether pressing forward with
this patch is best. IIUC this didn't arise from any user complaint but
rather just thinking about the problem. And, while I agree it could be
confusing in some situations, in practice it seems that perhaps it has
never actually bitten anybody.
Tom