[RFC] setting the raw content of a register

[RFC] setting the raw content of a register

[Jerome Guitton]

When trying to set the raw content of a fp register, many users try
something like:

(gdb) set $f14 := 0xFFF0000000000050
(gdb) info registers $f14
f14            -4503599627370416.0      (raw 0xc32fffffffffff60)

Of course, GDB sets the value of $f14, not its raw content. Now
this can be worked around by writing the raw content in memory,
re-read it as a float and store the value into register f14. Quite
kludgy though, and it often hits some limitations of the interpreter
regarding floats (e.g. signs of NaN are lost).

Maybe the simplest solution would be to add a new command to set the
raw content of a register. Attached a first candidate implementation,
to give an idea of how it could look like. The name of the command
here is "set register", but I would be happy to change it.

(gdb) help set register
Write raw value into register
Usage: set register REGNAME VALUE.
(gdb) set register f14 0xFFF0000000000050
(gdb) info registers $f14
f14            NaN(0x000000050) (raw 0xfff0000000000050)

Of course this would need some documentation, a new testcase, and
maybe a new python command as well (?). But I'd like to have your
opinion on the general idea first.

gdb/ChangeLog:

	* printcmd.c (set_register_command): New function.
	(_initialize_printcmd): New command "set register".
---
 gdb/printcmd.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/gdb/printcmd.c b/gdb/printcmd.c
index 030a4f2..7080d0e 100644
--- a/gdb/printcmd.c
+++ b/gdb/printcmd.c
@@ -49,6 +49,8 @@
 #include "charset.h"
 #include "arch-utils.h"
 #include "cli/cli-utils.h"
+#include "regcache.h"
+#include "user-regs.h"
 
 #ifdef TUI
 #include "tui/tui.h"		/* For tui_active et al.   */
@@ -1077,6 +1079,34 @@ output_command (char *exp, int from_tty)
 }
 
 static void
+set_register_command (char *exp, int from_tty)
+{
+  struct regcache *cache = get_current_regcache();
+  char *regname = exp, *exp2 = exp;
+  struct expression *expr;
+  struct cleanup *old_chain;
+  struct value *val, *reg;
+  int regnum;
+
+  exp2 = skip_to_space (exp);
+  if (*exp == '\0' || *exp2 == '\0')
+    error_no_arg (_("Two arguments required."));
+  *exp2 = '\0';
+  exp2 += 1;
+
+  regnum = user_reg_map_name_to_regnum (get_regcache_arch (cache),
+					regname, strlen (regname));
+  if (regnum == -1)
+    error (_("First argument must be a register."));
+
+  expr = parse_expression (exp2);
+  old_chain = make_cleanup (free_current_contents, &expr);
+  val = evaluate_expression (expr);
+  regcache_raw_write_unsigned (cache, regnum, value_as_long (val));
+  do_cleanups (old_chain);
+}
+
+static void
 set_command (char *exp, int from_tty)
 {
   struct expression *expr = parse_expression (exp);
@@ -2851,6 +2881,11 @@ variable in the program being debugged.  EXP is any valid expression.\n\
 This may usually be abbreviated to simply \"set\"."),
 	   &setlist);
 
+  add_cmd ("register", class_vars, set_register_command, _("\
+Write raw value into register\n\
+Usage: set register REGNAME VALUE."),
+	   &setlist);
+
   c = add_com ("print", class_vars, print_command, _("\
 Print value of expression EXP.\n\
 Variables accessible are those of the lexical environment of the selected\n\
-- 
1.7.0.2

Re: [RFC] setting the raw content of a register

[Pedro Alves]

On 05/22/2012 03:36 PM, Jerome Guitton wrote:

> When trying to set the raw content of a fp register, many users try
> something like:
> 
> (gdb) set $f14 := 0xFFF0000000000050
> (gdb) info registers $f14
> f14            -4503599627370416.0      (raw 0xc32fffffffffff60)
> 
> Of course, GDB sets the value of $f14, not its raw content. Now
> this can be worked around by writing the raw content in memory,
> re-read it as a float and store the value into register f14. Quite
> kludgy though, and it often hits some limitations of the interpreter
> regarding floats (e.g. signs of NaN are lost).


What about :

  p $f14 = {double} {0xFFF0000000000050}

?

-- 
Pedro Alves

Re: [RFC] setting the raw content of a register

[Jerome Guitton]

Pedro Alves (palves@redhat.com):

> What about :
> 
>   p $f14 = {double} {0xFFF0000000000050}

I've been testing with a bareboard PPC, and this needs malloc;
let me check how it would work on a target with malloc. Any chance
that it would give me something different than my macro "raw_to_double"
(that uses the stack instead of the heap)?

 define raw_to_double
 set $stack_content = *((long long *) ($sp - 8))
 set *((long long *) ($sp - 8)) = $arg0
 x/2x ((double *) ($sp - 8))
 p *((double *) ($sp - 8))
 set *((long long *) ($sp - 8)) = $stack_content
 end

(gdb) raw_to_double 0xFFF0000000000050
0x1fffd8:       0xfff00000      0x00000050
$3 = -nan(0x000000050)
(gdb) set $f14 = $
(gdb) info registers $f14
f14            nan(0x100000001) (raw 0x7ff0000100000001)

Re: [RFC] setting the raw content of a register

[Pedro Alves]

On 05/22/2012 04:24 PM, Jerome Guitton wrote:

> Pedro Alves (palves@redhat.com):
> 
>> What about :
>>
>>   p $f14 = {double} {0xFFF0000000000050}
> 
> I've been testing with a bareboard PPC, and this needs malloc;


Hmm, looks like you're right.  I was almost certain there was a way
to avoid the malloc if the cast/conversion is done to a type of
the exact same size as the source array, but it's escaping me now
how.

-- 
Pedro Alves

Re: [RFC] setting the raw content of a register

[Doug Evans]

On Tue, May 22, 2012 at 9:31 AM, Pedro Alves <palves@redhat.com> wrote:
> On 05/22/2012 04:24 PM, Jerome Guitton wrote:
>
>> Pedro Alves (palves@redhat.com):
>>
>>> What about :
>>>
>>>   p $f14 = {double} {0xFFF0000000000050}
>>
>> I've been testing with a bareboard PPC, and this needs malloc;
>
>
> Hmm, looks like you're right.  I was almost certain there was a way
> to avoid the malloc if the cast/conversion is done to a type of
> the exact same size as the source array, but it's escaping me now
> how.

IWBN to solve this without adding a new command, the problem is more
general than just assigning values to registers.  I may want to use
the value in an expression, for example.

Re: [RFC] setting the raw content of a register

[Pedro Alves]

On 05/23/2012 04:21 PM, Doug Evans wrote:

> On Tue, May 22, 2012 at 9:31 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 05/22/2012 04:24 PM, Jerome Guitton wrote:
>>
>>> Pedro Alves (palves@redhat.com):
>>>
>>>> What about :
>>>>
>>>>   p $f14 = {double} {0xFFF0000000000050}
>>>
>>> I've been testing with a bareboard PPC, and this needs malloc;
>>
>>
>> Hmm, looks like you're right.  I was almost certain there was a way
>> to avoid the malloc if the cast/conversion is done to a type of
>> the exact same size as the source array, but it's escaping me now
>> how.
> 
> IWBN to solve this without adding a new command, the problem is more
> general than just assigning values to registers.  I may want to use
> the value in an expression, for example.


Agreed.

-- 
Pedro Alves

Re: [RFC] setting the raw content of a register

[Jerome Guitton]

Doug Evans (dje@google.com):

> On Tue, May 22, 2012 at 9:31 AM, Pedro Alves <palves@redhat.com> wrote:
> > On 05/22/2012 04:24 PM, Jerome Guitton wrote:
> >
> >> Pedro Alves (palves@redhat.com):
> >>
> >>> What about :
> >>>
> >>>   p $f14 = {double} {0xFFF0000000000050}
> >>
> >> I've been testing with a bareboard PPC, and this needs malloc;
> >
> >
> > Hmm, looks like you're right.  I was almost certain there was a way
> > to avoid the malloc if the cast/conversion is done to a type of
> > the exact same size as the source array, but it's escaping me now
> > how.
> 
> IWBN to solve this without adding a new command, the problem is more
> general than just assigning values to registers.  I may want to use
> the value in an expression, for example.

I can have a look.

Still, we will have the problem that I was mentioning for cross
targets: we sometimes lose the sign of the NaN. e.g. when debugging a
ppc-elf target from a x86-linux host, {double} {0xFFF0000000000050}
probably evaluates to NaN(0x100000001) instead of
-NaN(0x000000050). Same kind of issue for denorms. We may improve the
precision of the evaluation here, but I fear that it will take some
time to catch all the possible cases. A new command would give a work
around to anyone hitting such a precision loss.

Re: [RFC] setting the raw content of a register

[Pedro Alves]

On 05/23/2012 04:42 PM, Jerome Guitton wrote:

> I can have a look.
> 
> Still, we will have the problem that I was mentioning for cross
> targets: we sometimes lose the sign of the NaN. e.g. when debugging a
> ppc-elf target from a x86-linux host, {double} {0xFFF0000000000050}
> probably evaluates to NaN(0x100000001) instead of
> -NaN(0x000000050). Same kind of issue for denorms. We may improve the
> precision of the evaluation here, but I fear that it will take some
> time to catch all the possible cases. A new command would give a work
> around to anyone hitting such a precision loss.


The idea was for that expression to result in no evaluation, but on a
reinterpret cast.  We can create GDB side arrays without involving the
inferior, like so:

(gdb) p {1}
$1 = {1}
(gdb) p sizeof {1}
$2 = 4

or:

(gdb) p/c (char[1]) {1}
$3 = {1 '\001'}

But we can't reinterpret / cast a byte array to anything else:

(gdb) p (char) $3
evaluation of this expression requires the target program to be active
(gdb) p (int) $1
evaluation of this expression requires the target program to be active

This is because we try to follow C's semantics, and try to decay the array
to a pointer.  And a pointer implies an address on the inferior, which implies
copying the array into the inferior, which requires malloc'ing a block of
memory in the inferior.

Sounds like we're missing a "reinterpret cast" operator, or steal some
invalid C cast syntax for the effect.

For non-scalars, we could just steal the regular cast:

struct foo
{
  char c;
};

(gdb) p (struct foo) (char[1]) {1}

as that is not a valid C cast ("error: conversion to non-scalar type requested" in gcc).

In fact, I think that'd be already quite useful.

But what to do with casts to scalars?

-- 
Pedro Alves

Re: [RFC] setting the raw content of a register

[Pedro Alves]

On 05/23/2012 05:02 PM, Pedro Alves wrote:

> On 05/23/2012 04:42 PM, Jerome Guitton wrote:
> 
>> I can have a look.
>>
>> Still, we will have the problem that I was mentioning for cross
>> targets: we sometimes lose the sign of the NaN. e.g. when debugging a
>> ppc-elf target from a x86-linux host, {double} {0xFFF0000000000050}
>> probably evaluates to NaN(0x100000001) instead of
>> -NaN(0x000000050). Same kind of issue for denorms. We may improve the
>> precision of the evaluation here, but I fear that it will take some
>> time to catch all the possible cases. A new command would give a work
>> around to anyone hitting such a precision loss.
> 
> 
> The idea was for that expression to result in no evaluation, but on a
> reinterpret cast.  We can create GDB side arrays without involving the
> inferior, like so:
> 
> (gdb) p {1}
> $1 = {1}
> (gdb) p sizeof {1}
> $2 = 4
> 
> or:
> 
> (gdb) p/c (char[1]) {1}
> $3 = {1 '\001'}
> 
> But we can't reinterpret / cast a byte array to anything else:
> 
> (gdb) p (char) $3
> evaluation of this expression requires the target program to be active
> (gdb) p (int) $1
> evaluation of this expression requires the target program to be active
> 
> This is because we try to follow C's semantics, and try to decay the array
> to a pointer.  And a pointer implies an address on the inferior, which implies
> copying the array into the inferior, which requires malloc'ing a block of
> memory in the inferior.
> 
> Sounds like we're missing a "reinterpret cast" operator, or steal some
> invalid C cast syntax for the effect.
> 
> For non-scalars, we could just steal the regular cast:
> 
> struct foo
> {
>   char c;
> };
> 
> (gdb) p (struct foo) (char[1]) {1}
> 
> as that is not a valid C cast ("error: conversion to non-scalar type requested" in gcc).
> 
> In fact, I think that'd be already quite useful.
> 
> But what to do with casts to scalars?
> 


Actually, casting arrays to floats appears to also be invalid.  I didn't check any
standard, but gcc gives:

struct foo { char c; };
char array[] = { 0xff };

int main ()
{
  float f = (float) array;
}

$ gcc array.c -o array
array.c: In function ‘main’:
array.c:6:3: error: pointer value used where a floating point value was expected

Still leaves scalars out though.

But I'm beginning to think I misunderstood where the precision is being lost.

-- 
Pedro Alves

Re: [RFC] setting the raw content of a register

[Joel Brobecker]

My two cents:

One of the concerns I have with the current discussion centering around
using the expression parser is that the syntax would then be language-
sensitive, or might not even be implemented/able in certain languages
at all. I can be a number of scenarios where that becomes a pain
for the user (assuming said user was able to find the right incantation
at all).

Also, I tend to think that the "{TYPE} VAL " expression is a little
obscure to be found easily by someone searching for a way to assign
a raw value to an object. And to widen the discussion, I have always
thought that relying on language expression assignment to change the
value of some variables or even some memory has always been a PIA, and
I would have welcomed a dedicated command to do that.

So, I understand the desire to widen the discussion to find a way
to change the raw value of any object, not just registers, but
I would really prefer in this instance that it did not rely on
pure expression evaluation.

-- 
Joel