* [PATCH] Assert on lval_register
@ 2016-11-30 14:56 Yao Qi
2016-11-30 21:16 ` Ulrich Weigand
0 siblings, 1 reply; 5+ messages in thread
From: Yao Qi @ 2016-11-30 14:56 UTC (permalink / raw)
To: gdb-patches
This patch adds asserts where the value's lval must be lval_register.
This triggers an error in frame_register_unwind because VALUE_REGNUM
is used but value's lval is not lval_register.
This also reveals a design issue in frame_register_unwind, that is
arguments addrp and realnump are mutually exclusive, we either use
addrp (for lval_memory), or use realnump (for lval_register). This
can be done in a separate patch.
Regression tested on x86_64-linux.
gdb:
2016-11-30 Yao Qi <yao.qi@linaro.org>
* frame.c (frame_register_unwind): Set *realnump if *lvalp is
lval_register.
* value.c (deprecated_value_next_frame_id_hack): Assert
value->lval is lval_register.
(deprecated_value_regnum_hack): Likewise.
---
gdb/frame.c | 3 ++-
gdb/value.c | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/gdb/frame.c b/gdb/frame.c
index 5414cb3..1c388d1 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -1107,7 +1107,8 @@ frame_register_unwind (struct frame_info *frame, int regnum,
*unavailablep = !value_entirely_available (value);
*lvalp = VALUE_LVAL (value);
*addrp = value_address (value);
- *realnump = VALUE_REGNUM (value);
+ if (*lvalp == lval_register)
+ *realnump = VALUE_REGNUM (value);
if (bufferp)
{
diff --git a/gdb/value.c b/gdb/value.c
index cc291cf..022900f 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1576,12 +1576,14 @@ deprecated_value_internalvar_hack (struct value *value)
struct frame_id *
deprecated_value_next_frame_id_hack (struct value *value)
{
+ gdb_assert (value->lval == lval_register);
return &value->location.reg.next_frame_id;
}
int *
deprecated_value_regnum_hack (struct value *value)
{
+ gdb_assert (value->lval == lval_register);
return &value->location.reg.regnum;
}
--
1.9.1
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] Assert on lval_register
2016-11-30 14:56 [PATCH] Assert on lval_register Yao Qi
@ 2016-11-30 21:16 ` Ulrich Weigand
2016-12-06 10:15 ` Yao Qi
0 siblings, 1 reply; 5+ messages in thread
From: Ulrich Weigand @ 2016-11-30 21:16 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb-patches
Yao Qi wrote:
> This patch adds asserts where the value's lval must be lval_register.
> This triggers an error in frame_register_unwind because VALUE_REGNUM
> is used but value's lval is not lval_register.
Makes sense to me.
> This also reveals a design issue in frame_register_unwind, that is
> arguments addrp and realnump are mutually exclusive, we either use
> addrp (for lval_memory), or use realnump (for lval_register). This
> can be done in a separate patch.
I think we should simply get rid of frame_register_unwind. Callers
should be changed to use frame_unwind_register_value directly, and
just operate on the value.
> *lvalp = VALUE_LVAL (value);
> *addrp = value_address (value);
> - *realnump = VALUE_REGNUM (value);
> + if (*lvalp == lval_register)
> + *realnump = VALUE_REGNUM (value);
But as long as the above change is not done yet, maybe we ought to
at least provide a defined value (e.g. -1), to avoid callers maybe
making use of uninitialized variables?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Assert on lval_register
2016-11-30 21:16 ` Ulrich Weigand
@ 2016-12-06 10:15 ` Yao Qi
2016-12-06 13:13 ` Ulrich Weigand
0 siblings, 1 reply; 5+ messages in thread
From: Yao Qi @ 2016-12-06 10:15 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
On 16-11-30 22:16:37, Ulrich Weigand wrote:
> > This also reveals a design issue in frame_register_unwind, that is
> > arguments addrp and realnump are mutually exclusive, we either use
> > addrp (for lval_memory), or use realnump (for lval_register). This
> > can be done in a separate patch.
>
> I think we should simply get rid of frame_register_unwind. Callers
> should be changed to use frame_unwind_register_value directly, and
> just operate on the value.
>
Yeah, that is what I was trying to do, but we should be careful on
the value management in the end of frame_register_unwind,
/* Dispose of the new value. This prevents watchpoints from
trying to watch the saved frame pointer. */
release_value (value);
value_free (value);
> > *lvalp = VALUE_LVAL (value);
> > *addrp = value_address (value);
> > - *realnump = VALUE_REGNUM (value);
> > + if (*lvalp == lval_register)
> > + *realnump = VALUE_REGNUM (value);
>
> But as long as the above change is not done yet, maybe we ought to
> at least provide a defined value (e.g. -1), to avoid callers maybe
> making use of uninitialized variables?
>
OK, how about the patch below?
--
Yao (é½å°§)
From 581e1b80ea631d5bcfb5fc64b07a36fd71f5d55e Mon Sep 17 00:00:00 2001
From: Yao Qi <yao.qi@linaro.org>
Date: Thu, 24 Nov 2016 09:08:00 +0000
Subject: [PATCH] Assert on lval_register
This patch adds asserts where the value's lval must be lval_register.
This triggers an error in frame_register_unwind because VALUE_REGNUM
is used but value's lval is not lval_register.
This also reveals a design issue in frame_register_unwind, that is
arguments addrp and realnump are mutually exclusive, we either use
addrp (for lval_memory), or use realnump (for lval_register). This
can be done in a separate patch.
gdb:
2016-12-06 Yao Qi <yao.qi@linaro.org>
* frame.c (frame_register_unwind): Set *realnump if *lvalp is
lval_register.
* value.c (deprecated_value_next_frame_id_hack): Assert
value->lval is lval_register.
(deprecated_value_regnum_hack): Likewise.
diff --git a/gdb/frame.c b/gdb/frame.c
index 5414cb3..00001bc 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -1107,7 +1107,10 @@ frame_register_unwind (struct frame_info *frame, int regnum,
*unavailablep = !value_entirely_available (value);
*lvalp = VALUE_LVAL (value);
*addrp = value_address (value);
- *realnump = VALUE_REGNUM (value);
+ if (*lvalp == lval_register)
+ *realnump = VALUE_REGNUM (value);
+ else
+ *realnump = -1;
if (bufferp)
{
diff --git a/gdb/value.c b/gdb/value.c
index cc291cf..022900f 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1576,12 +1576,14 @@ deprecated_value_internalvar_hack (struct value *value)
struct frame_id *
deprecated_value_next_frame_id_hack (struct value *value)
{
+ gdb_assert (value->lval == lval_register);
return &value->location.reg.next_frame_id;
}
int *
deprecated_value_regnum_hack (struct value *value)
{
+ gdb_assert (value->lval == lval_register);
return &value->location.reg.regnum;
}
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] Assert on lval_register
2016-12-06 10:15 ` Yao Qi
@ 2016-12-06 13:13 ` Ulrich Weigand
2016-12-06 14:26 ` Yao Qi
0 siblings, 1 reply; 5+ messages in thread
From: Ulrich Weigand @ 2016-12-06 13:13 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb-patches
Yao Qi wrote:
> On 16-11-30 22:16:37, Ulrich Weigand wrote:
> > I think we should simply get rid of frame_register_unwind. Callers
> > should be changed to use frame_unwind_register_value directly, and
> > just operate on the value.
>
> Yeah, that is what I was trying to do, but we should be careful on
> the value management in the end of frame_register_unwind,
>
> /* Dispose of the new value. This prevents watchpoints from
> trying to watch the saved frame pointer. */
> release_value (value);
> value_free (value);
Right. Those callers that care will need to handle this themselves.
> OK, how about the patch below?
Looks good to me.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-12-06 14:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-30 14:56 [PATCH] Assert on lval_register Yao Qi
2016-11-30 21:16 ` Ulrich Weigand
2016-12-06 10:15 ` Yao Qi
2016-12-06 13:13 ` Ulrich Weigand
2016-12-06 14:26 ` Yao Qi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox