This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]