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

[Pedro Alves <palves@redhat.com>]

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