Setting a floating point register to raw hex value

Does any one know of a way to set a floating point register
($f0) to a
arbitrary raw hex value (for example 1)

I tried the following.

(gdb) set $f0 = 5.0000000000000000e-324
(gdb) p $f0
$1 = -1.5966722476277758e+293
(gdb) set $f0 = 5.0000000000000000e-324

The value of 5.0000000000000000e-324 should correspond to
0x0000000000000001 in raw hex

Any ideas?

I am using ppc7450 (G4) if that helps.

I have figured out a workaround but it is really ugly.

Step 1:  Create shared object containing a union as follows
union longlong2double
{
long long int hexNum;
double floatNum;
} temp;

Step 2: Force load the library at runtime into your program
using
LD_PRELOAD environmental variable

Step 3: When debugging the program store 0x1 into
temp.hexNum;
(one would think that I could use the following now 'set $f0
=
temp.floatNum; but that yields incorrect result)

Step4:  Overwrite the current instruction with 'load float'

Step5: Using stepping command 'stepi 1' to write the value
to the $f0

Step6: Undo all the changes required by steps 4 and 5

Does any one know of a simpler way because this workaround
is crazy?


Greg Cieslewski



On 10/12/07, Grzegorz Cieslewski <cieslewskihcs.ufl.edu> wrote:
> Does any one know of a way to set a floating point
register ($f0) to a
> arbitrary raw hex value (for example 1)
>
> I tried the following.
>
> (gdb) set $f0 = 5.0000000000000000e-324
> (gdb) p $f0
> $1 = -1.5966722476277758e+293
> (gdb) set $f0 = 5.0000000000000000e-324
>
> The value of 5.0000000000000000e-324 should correspond
to
> 0x0000000000000001 in raw hex
>
> Any ideas?
>
> I am using ppc7450 (G4) if that helps.
>

Hi,

Yes, that's indeed crazy. 

Just found out that this works:

(gdb) set (void *) $f1 = 0x1
(gdb) info reg f1
f1             4.9406564584124654e-324  (raw
0x0000000000000001)
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center



On Thu, 2007-10-18 at 15:38 -0400, Grzegorz Cieslewski
wrote:
> I have figured out a workaround but it is really ugly.
> 
> Step 1:  Create shared object containing a union as
follows
> union longlong2double
> {
> long long int hexNum;
> double floatNum;
> } temp;
> 
> Step 2: Force load the library at runtime into your
program using
> LD_PRELOAD environmental variable
> 
> Step 3: When debugging the program store 0x1 into
temp.hexNum;
> (one would think that I could use the following now
'set $f0 =
> temp.floatNum; but that yields incorrect result)
> 
> Step4:  Overwrite the current instruction with 'load
float'
> 
> Step5: Using stepping command 'stepi 1' to write the
value to the $f0
> 
> Step6: Undo all the changes required by steps 4 and 5
> 
> Does any one know of a simpler way because this
workaround is crazy?
> 
> 
> Greg Cieslewski
> 
> 
> 
> On 10/12/07, Grzegorz Cieslewski <cieslewskihcs.ufl.edu> wrote:
> > Does any one know of a way to set a floating point
register ($f0) to a
> > arbitrary raw hex value (for example 1)
> >
> > I tried the following.
> >
> > (gdb) set $f0 = 5.0000000000000000e-324
> > (gdb) p $f0
> > $1 = -1.5966722476277758e+293
> > (gdb) set $f0 = 5.0000000000000000e-324
> >
> > The value of 5.0000000000000000e-324 should
correspond to
> > 0x0000000000000001 in raw hex
> >
> > Any ideas?
> >
> > I am using ppc7450 (G4) if that helps.
> >

I have tried that solution, on the powerpc/ubuntu6.10 with
gdb 6.7  and get:
(gdb) set (void*) $f0 = 0x1
Invalid cast.

I have also tried that on older x86 box with Redhat 9 with
similar result
(gdb) set (void*) $R0 = 0x1
Invalid cast.


Could this some sort of platform dependent bug?

On 10/18/07, Thiago Jung Bauermann <bauermanbr.ibm.com> wrote:
> Hi,
>
> Yes, that's indeed crazy. 
>
> Just found out that this works:
>
> (gdb) set (void *) $f1 = 0x1
> (gdb) info reg f1
> f1             4.9406564584124654e-324  (raw
0x0000000000000001)
> --
> []'s
> Thiago Jung Bauermann
> Software Engineer
> IBM Linux Technology Center
>
>
>
> On Thu, 2007-10-18 at 15:38 -0400, Grzegorz Cieslewski
wrote:
> > I have figured out a workaround but it is really
ugly.
> >
> > Step 1:  Create shared object containing a union
as follows
> > union longlong2double
> > {
> > long long int hexNum;
> > double floatNum;
> > } temp;
> >
> > Step 2: Force load the library at runtime into
your program using
> > LD_PRELOAD environmental variable
> >
> > Step 3: When debugging the program store 0x1 into
temp.hexNum;
> > (one would think that I could use the following
now 'set $f0 =
> > temp.floatNum; but that yields incorrect result)
> >
> > Step4:  Overwrite the current instruction with
'load float'
> >
> > Step5: Using stepping command 'stepi 1' to write
the value to the $f0
> >
> > Step6: Undo all the changes required by steps 4
and 5
> >
> > Does any one know of a simpler way because this
workaround is crazy?
> >
> >
> > Greg Cieslewski
> >
> >
> >
> > On 10/12/07, Grzegorz Cieslewski
<cieslewskihcs.ufl.edu> wrote:
> > > Does any one know of a way to set a floating
point register ($f0) to a
> > > arbitrary raw hex value (for example 1)
> > >
> > > I tried the following.
> > >
> > > (gdb) set $f0 = 5.0000000000000000e-324
> > > (gdb) p $f0
> > > $1 = -1.5966722476277758e+293
> > > (gdb) set $f0 = 5.0000000000000000e-324
> > >
> > > The value of 5.0000000000000000e-324 should
correspond to
> > > 0x0000000000000001 in raw hex
> > >
> > > Any ideas?
> > >
> > > I am using ppc7450 (G4) if that helps.
> > >
>
>
>

On Thu, Oct 18, 2007 at 06:16:00PM -0200, Thiago Jung
Bauermann wrote:
> Hi,
> 
> Yes, that's indeed crazy. 
> 
> Just found out that this works:
> 
> (gdb) set (void *) $f1 = 0x1
> (gdb) info reg f1
> f1             4.9406564584124654e-324  (raw
0x0000000000000001)

I think this only works by an accident involving
gdbarch_convert_register_p on PowerPC.  We should find some
proper way
to do it, document that, and then make this not work 

> On Thu, 2007-10-18 at 15:38 -0400, Grzegorz Cieslewski
wrote:
> > I have figured out a workaround but it is really
ugly.
> > 
> > Step 1:  Create shared object containing a union
as follows
> > union longlong2double
> > {
> > long long int hexNum;
> > double floatNum;
> > } temp;
> > 
> > Step 2: Force load the library at runtime into
your program using
> > LD_PRELOAD environmental variable
> > 
> > Step 3: When debugging the program store 0x1 into
temp.hexNum;
> > (one would think that I could use the following
now 'set $f0 =
> > temp.floatNum; but that yields incorrect result)
> > 
> > Step4:  Overwrite the current instruction with
'load float'
> > 
> > Step5: Using stepping command 'stepi 1' to write
the value to the $f0
> > 
> > Step6: Undo all the changes required by steps 4
and 5
> > 
> > Does any one know of a simpler way because this
workaround is crazy?

Sure, here's a much easier way that ought to work:

(gdb) set {long long} ($sp - 8) = 1
(gdb) set $f0 =  ($sp - 8)

Doesn't have to be $sp - 8, any memory address will do.

Oddly, this does not work on PowerPC.  I can't figure out
why
not.  It certainly ought to work; perhaps it requires a
current
version of GDB, since 0x1 is a denormal.  It does work for
normals,
though, so I know the approach is sound.

-- 
Daniel Jacobowitz
CodeSourcery

On Thu, 2007-10-18 at 17:54 -0400, Daniel Jacobowitz wrote:
> On Thu, Oct 18, 2007 at 06:16:00PM -0200, Thiago Jung
Bauermann wrote:
> > Hi,
> > 
> > Yes, that's indeed crazy. 
> > 
> > Just found out that this works:
> > 
> > (gdb) set (void *) $f1 = 0x1
> > (gdb) info reg f1
> > f1             4.9406564584124654e-324  (raw
0x0000000000000001)
> 
> I think this only works by an accident involving
> gdbarch_convert_register_p on PowerPC.  We should find
some proper way
> to do it, document that, and then make this not work


You're just spoiling the fun. 

You mean that rs6000_convert_register_p should return true
for every
type that's not double, and then GDB would try to convert a
void * to a
double and fail?

I see in value_assign that $f1 in the expression I gave
above is being
represented as a value struct in register $f1 with void *
type. Wouldn't
it be reasonable for value_assign to see that this register
is being
used with a type different than it's default (double) and
figure that
the user wants to use the register in a different way and
just let him
do that?

> > On Thu, 2007-10-18 at 15:38 -0400, Grzegorz
Cieslewski wrote:
> > > I have figured out a workaround but it is
really ugly.
> > > 
> > > Step 1:  Create shared object containing a
union as follows
> > > union longlong2double
> > > {
> > > long long int hexNum;
> > > double floatNum;
> > > } temp;
> > > 
> > > Step 2: Force load the library at runtime
into your program using
> > > LD_PRELOAD environmental variable
> > > 
> > > Step 3: When debugging the program store 0x1
into temp.hexNum;
> > > (one would think that I could use the
following now 'set $f0 =
> > > temp.floatNum; but that yields incorrect
result)
> > > 
> > > Step4:  Overwrite the current instruction
with 'load float'
> > > 
> > > Step5: Using stepping command 'stepi 1' to
write the value to the $f0
> > > 
> > > Step6: Undo all the changes required by steps
4 and 5
> > > 
> > > Does any one know of a simpler way because
this workaround is crazy?
> 
> Sure, here's a much easier way that ought to work:
> 
> (gdb) set {long long} ($sp - 8) = 1
> (gdb) set $f0 =  ($sp - 8)
> 
> Doesn't have to be $sp - 8, any memory address will
do.

$sp - 8 will mess with the function's frame if he happens to
be stepping
through the prologue. Just telling to make sure Grzegorz is
aware of
it...

> Oddly, this does not work on PowerPC.  I can't figure
out why
> not.  It certainly ought to work; perhaps it requires a
current
> version of GDB, since 0x1 is a denormal.  It does work
for normals,
> though, so I know the approach is sound.

It worked for me in GDB 6.7 but not in HEAD.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

On Fri, Oct 19, 2007 at 05:48:05PM -0200, Thiago Jung
Bauermann wrote:
> You mean that rs6000_convert_register_p should return
true for every
> type that's not double, and then GDB would try to
convert a void * to a
> double and fail?

Maybe.  To be honest, I didn't think that would reach this
point at
all for the expression "(void *) $f0".  I thought
that would take the
value of the register and call value_cast.  But I guess
that's not
happening, or else we're marking the result of the cast as
an lvalue.

GCC stopped doing that; maybe we should too.

What we really want here is not:

  set (long) $f0 = 0x1

but rather something like:

  set $f0 = reinterpret_cast<double>(0x1)

No, I'm not seriously suggesting we implement
reinterpret_cast, which
C++ wouldn't let us use like that anyway.
> $sp - 8 will mess with the function's frame if he
happens to be stepping
> through the prologue. Just telling to make sure
Grzegorz is aware of
> it...

Depends on the architecture - only if you have a red zone.

> > Oddly, this does not work on PowerPC.  I can't
figure out why
> > not.  It certainly ought to work; perhaps it
requires a current
> > version of GDB, since 0x1 is a denormal.  It does
work for normals,
> > though, so I know the approach is sound.
> 
> It worked for me in GDB 6.7 but not in HEAD.

Hmm, failed for me in 6.6.

-- 
Daniel Jacobowitz
CodeSourcery

Thank you all for help.

In the end since there is no "clean" way of
addressing my problem I
have merged the ideas into one.

I decided that forcing shared library to load is slightly
better than
overwriting a random memory location (I would have to fix
that before
continuing to execute the program).  The shared library
contains only
one global variable which is a array of chars. Then I use
the method
suggested by Thiago:
(gdb) set {long long} ($temp_xyz) = 1
(gdb) set $f0 =  ($temp_xyz)




On 10/19/07, Thiago Jung Bauermann <bauermanbr.ibm.com> wrote:
> On Thu, 2007-10-18 at 17:54 -0400, Daniel Jacobowitz
wrote:
> > On Thu, Oct 18, 2007 at 06:16:00PM -0200, Thiago
Jung Bauermann wrote:
> > > Hi,
> > >
> > > Yes, that's indeed crazy. 
> > >
> > > Just found out that this works:
> > >
> > > (gdb) set (void *) $f1 = 0x1
> > > (gdb) info reg f1
> > > f1             4.9406564584124654e-324  (raw
0x0000000000000001)
> >
> > I think this only works by an accident involving
> > gdbarch_convert_register_p on PowerPC.  We should
find some proper way
> > to do it, document that, and then make this not
work 
>
> You're just spoiling the fun. 
>
> You mean that rs6000_convert_register_p should return
true for every
> type that's not double, and then GDB would try to
convert a void * to a
> double and fail?
>
> I see in value_assign that $f1 in the expression I gave
above is being
> represented as a value struct in register $f1 with void
* type. Wouldn't
> it be reasonable for value_assign to see that this
register is being
> used with a type different than it's default (double)
and figure that
> the user wants to use the register in a different way
and just let him
> do that?
>
> > > On Thu, 2007-10-18 at 15:38 -0400, Grzegorz
Cieslewski wrote:
> > > > I have figured out a workaround but it
is really ugly.
> > > >
> > > > Step 1:  Create shared object containing
a union as follows
> > > > union longlong2double
> > > > {
> > > > long long int hexNum;
> > > > double floatNum;
> > > > } temp;
> > > >
> > > > Step 2: Force load the library at
runtime into your program using
> > > > LD_PRELOAD environmental variable
> > > >
> > > > Step 3: When debugging the program store
0x1 into temp.hexNum;
> > > > (one would think that I could use the
following now 'set $f0 =
> > > > temp.floatNum; but that yields incorrect
result)
> > > >
> > > > Step4:  Overwrite the current
instruction with 'load float'
> > > >
> > > > Step5: Using stepping command 'stepi 1'
to write the value to the $f0
> > > >
> > > > Step6: Undo all the changes required by
steps 4 and 5
> > > >
> > > > Does any one know of a simpler way
because this workaround is crazy?
> >
> > Sure, here's a much easier way that ought to
work:
> >
> > (gdb) set {long long} ($sp - 8) = 1
> > (gdb) set $f0 =  ($sp - 8)
> >
> > Doesn't have to be $sp - 8, any memory address
will do.
>
> $sp - 8 will mess with the function's frame if he
happens to be stepping
> through the prologue. Just telling to make sure
Grzegorz is aware of
> it...
>
> > Oddly, this does not work on PowerPC.  I can't
figure out why
> > not.  It certainly ought to work; perhaps it
requires a current
> > version of GDB, since 0x1 is a denormal.  It does
work for normals,
> > though, so I know the approach is sound.
>
> It worked for me in GDB 6.7 but not in HEAD.
> --
> []'s
> Thiago Jung Bauermann
> Software Engineer
> IBM Linux Technology Center
>
>


-- 
=====================================================
Grzegorz Cieslewski
Research Assistant
High-performance Computing & Simulation (HCS) Research
Laboratory
University of Florida, Dept. of Electrical and Computer
Engineering
330 Benton Hall, Gainesville, FL, 32611-6200
Phone: (352) 392-9041
Email: cieslewskihcs.ufl.edu
Web: www.hcs.ufl.edu
=====================================================