Double precision floats and GDB

They are not human readable in memory like integers, so if you are examining memory in GDB session it is not very likely that you will recognize what number is it. Their layout in memory is specified by IEEE 754 standard. They occupy 64 bits and there is one bit for sign, 11 bits for exponent and 52 bits significand. There is really plenty of read about floats on the web and I will not bother you with theory, significance of their discrete spectrum, rounding and similar. Just want to show you how to handle them during debug session.
I have seen in some lecture, can't remember exactly where, solution to examine memory layout via struct and union. Here is my interpretation of it:

#include <stdio.h> typedef struct double_storage { unsigned long mantissa:52; unsigned int exponent:11; unsigned int sign:1; } Double; typedef union double_helper { double number; Double storage; } Helper; int main(){ Helper dbl = {3.141592653589793}; printf("number = %16.15lf sign = %u, exponent = %u, mantissa = %lu\n", dbl.number, dbl.storage.sign, dbl.storage.exponent, dbl.storage.mantissa); printf("number = %16.15g sign = %X, exponent = %X, mantissa = %lX\n", dbl.number, dbl.storage.sign, dbl.storage.exponent, dbl.storage.mantissa); return 0; }

In struct we have specified layout and union is helper so that we can see number in human readable representation. We compile it using GCC -g switch and we start GDB session to examine how layout looks like. Before that we execute program once and save output so that we can recognize our number, the second printf is of interest.

number = 3.14159265358979 sign = 0, exponent = 400, mantissa = 921FB54442D18

Here is debug session, rather most interesting parts:

(gdb) print &dbl $1 = (Helper *) 0x7fffffffe700 (gdb) x/2x 0x7fffffffe700 0x7fffffffe700: 0x54442d18 0x400921fb

After variable is initialized we queried address of it and then we asked for two units to be printed in hex format. Just to be on the safe side, let us print them 32bit by 32bit and 4 bytes by 4 bytes as well

(gdb) x/x 0x7fffffffe704 0x7fffffffe704: 0x400921fb (gdb) x/4b 0x7fffffffe704 0x7fffffffe704: 0xfb 0x21 0x09 0x40 (gdb) x/x 0x7fffffffe700 0x7fffffffe700: 0x54442d18 (gdb) x/4b 0x7fffffffe700 0x7fffffffe700: 0x18 0x2d 0x44 0x54

Where we clearly have little-endian layout in memory, least significant byte at lowest address. The same number in register

(gdb) print/x $rax $4 = 0x400921fb54442d18 (gdb) print/x $eax $5 = 0x54442d18 (gdb) print/x $ax $6 = 0x2d18 (gdb) print/x $al $7 = 0x18

Here we do not really have address so no endianness either. Maybe we could just use f format?

(gdb) x/f 0x7fffffffe700 0x7fffffffe700: 3.1415926535897931