This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] setting the raw content of a register
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