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

C pointers, assembler and GDB

Idea here is to do some multitasking, find out how C pointer looks like in assembler and use Linux system calls, GCC and GDB. We start with Hello World:

int main() { char *c = "Hello World!\n"; write(1, c, 13); return 0; }

Execute man 2 write in terminal to find out more about write, 1 is standard output and 12 is number of bytes to be written. I saved it as hello.c and this is how it was compiled:

gcc -O0 -m64 -save-temps -o hlo hello.c

GCC will emit assembly code as temp, I like 64 bit version and no optimizations. Content of temp file is:

.file "hello.c" .section .rodata .LC0: .string "Hello World!\n" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 subq $16, %rsp movq $.LC0, -8(%rbp) movq -8(%rbp), %rax movl $13, %edx movq %rax, %rsi movl $1, %edi movl $0, %eax call write movl $0, %eax leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (Debian 4.7.2-5) 4.7.2" .section .note.GNU-stack,"",@progbits

It pushes base pointer onto stack, there is q at the end of the push and bp is called rbp, so it must be 64 bit code. Loads string into memory, later into rax, prepares call to write and so on. Now we take that temp file and compile it with -g switch so that we can use GDB.

gcc -g -O0 -o hlo hello.s
gdb hlo

We type in start at prompt and here is the GDB session:

Temporary breakpoint 1, main () at hello.s:16 16 subq $16, %rsp (gdb) n 17 movq $.LC0, -8(%rbp) (gdb) i r rbp rbp 0x7fffffffe360 0x7fffffffe360 (gdb) x 0x7fffffffe358 0x7fffffffe358: 0x00000000 (gdb) n 18 movq -8(%rbp), %rax (gdb) x 0x7fffffffe358 0x7fffffffe358: 0x004005ec (gdb) x/13c 0x004005ec 0x4005ec: 72 'H' 101 'e' 108 'l' 108 'l' 111 'o' 32 ' ' 87 'W' 111 'o' 0x4005f4: 114 'r' 108 'l' 100 'd' 33 '!' 10 '\n'

Label .LCO is our string, -8(%rbp) is where pointer is. After info registers in short form, I also restricted info to rbp, I find out that rbp points to  0x7fffffffe360 and at  0x7fffffffe360 - 8 = 0x7fffffffe358 is our pointer. No, 0x60 - 8 is not 0x52. After we send next instruction and line 17 is executed we can see our string in memory, slash 13 c is we want 13 characters from that address.
Since write is Linux system call, we can use strace to see what is going on.

strace -tt ./hlo 08:13:04.407694 execve("./hlo", ["./hlo"], [/* 37 vars */]) = 0 ... 08:13:04.412892 write(1, "Hello World!\n", 13Hello World! ) = 13 08:13:04.413108 exit_group(0) = ?

After quite few lines were replaced with three consecutive dots we see that we managed to write all 13 characters to standard output.
Using system calls is so easy that one may even attempt writing to real file:

#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> int main() { char *c = "Hello World!\n"; int fd; fd = open("deleteme.blog", O_WRONLY | O_CREAT | O_TRUNC | O_APPEND, S_IRUSR | S_IWUSR); if (fd == -1){ write(1, "Open failed!", 12); return 1; } if(write(fd, c, 13)!=13) write(1, "Write failed!", 13); if(close(fd)==-1){ write(1, "Close failed!", 13); return 1; } return 0; }

We added more system calls. We applied common flags and modes in open, checked for all possible errors, after writing string to file we have closed file. If we compile it using

gcc -O0 -m64 -save-temps -o hello2 hello.c

We have binary and also assembly code. With help of strace

strace -tt ./hello2 09:24:49.906151 execve("./hello2", ["./hello2"], [/* 37 vars */]) = 0 ... 09:24:49.911601 open("deleteme.blog", O_WRONLY|O_CREAT|O_TRUNC|O_APPEND, 0600) = 3 09:24:49.911842 write(3, "Hello World!\n", 13) = 13 09:24:49.912018 close(3) = 0 09:24:49.912386 exit_group(0) = ?

Executing cat deleteme.blog we see that write really worked and strace didn't cheat. Examining assembly code will be interesting to those who are curious how if works on low level. Finally every project manager will take a note that from 08:13:04.407694 to 09:24:49.906151 I have written only 21 line of code.

Tests, pointers, arrays and GDB

While I was looking for work, actually I am still looking for work, they sent me to do some tests. Those are some “tech check” rubbish tests which are testing how much of man pages you know by hart. Not do you have logic of programmer and real working knowledge but how well have you memorized help files. So let me explain how you are going to deal with those test and real life problems in sensible way. While agile approach is very desirable in project management, memorizing help files is what industry expects from programmers. Everything further happens on Linux and we will do some debugging to find out answers.
About every book teaching C contains story how one can declare array and access array elements via pointer arithmetic. Something like this:

int arr1d[] = {1, 2, 3, 4, 5}, i; for(i=0;i<5;i++) printf("i = %d; %d = %d = %d\n", i, *arr1d+i, *(arr1d+i), arr1d[i]);

Expression *arr1d+i is not really pointer arithmetic since dereferencing will happen before addition, and everybody who worked in C longer than two weeks knows it, but it will also produce desired result. I also omitted array length and gcc managed to read it from initializer. Now we can declare some pointers and assign address of our array to them.

int *p1d = arr1d; for(i=0;i<5;i++) printf("i = %d; %d = %d\n", i, *(p1d+i), p1d[i]);

Array is just pointer to its first element, we got type and everything right. If we now take address of array we will have double pointer? Not really.

int **p1d12 = &arr1d;

Produces this warning:

warning: initialization from incompatible pointer type [enabled by default]

Since we do not know what is wrong, what type for pointer to array we are getting instead double pointer to integer, we will ask GDB. This is the code:

#include <stdio.h> int main(){ int arr1d[] = {1, 2, 3, 4, 5}, i; for(i=0;i<5;i++) printf("i = %d; %d = %d = %d\n", i, *arr1d+i, *(arr1d+i), arr1d[i]); int *p1d = arr1d; for(i=0;i<5;i++) printf("i = %d; %d = %d\n", i, *(p1d+i), p1d[i]); int **p1d12 = &arr1d; /* not really */ int *p1d11 = &arr1d[0]; return 0; }

and we will save it as untitled.c and build using

gcc -g -Wall -o untitled untitled.c
untitled.c: In function ‘main’:
untitled.c:12:16: warning: initialization from incompatible pointer type [enabled by default]
untitled.c:13:7: warning: unused variable ‘p1d11’ [-Wunused-variable]
untitled.c:12:8: warning: unused variable ‘p1d12’ [-Wunused-variable]

This is together with output. Switch -g means that we want debugg info and -Wall that we want all warnings. Now we start interactive session and ask GDB what we want to know:

gdb untitled GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. … more advertising stuff … Reading symbols from ~/workshop/lrhw/untitled...done. (gdb) start Temporary breakpoint 1 at 0x4004fc: file untitled.c, line 4. Starting program: ~/workshop/lrhw/untitled Temporary breakpoint 1, main () at untitled.c:4 4 int arr1d[] = {1, 2, 3, 4, 5}, i; (gdb) info locals arr1d = {-6136, 32767, 4195877, 0, 1} i = 0 p1d = 0x0 p1d12 = 0x400410 p1d11 = 0x7fffffffe7f0 (gdb) next 5 for(i=0;i<5;i++) (gdb) info locals arr1d = {1, 2, 3, 4, 5} i = 0 p1d = 0x0 p1d12 = 0x400410 p1d11 = 0x7fffffffe7f0 (gdb) print arr1d $1 = {1, 2, 3, 4, 5} (gdb) print &arr1d $2 = (int (*)[5]) 0x7fffffffe6d0

It printed few lines of messages about license, where to report bugs and similar and loaded symbols for untitled. On prompt (gdb) we type in start and it starts and breaks on the first possible line. We try info locals and see that array is not initialized yet, so we execute next. Now array is initialized and we print it. Finally we ask it to print &arr1d and we learn what is the type of our “double pointer”.

int (*p1d12)[] = &arr1d;

This is what address of array returns and how “double pointer” should be declared, really ugly question on some idiotic test.
Things are becoming more interesting with multidimensional arrays. For example:

int arr2d[][4] = {{1, 2, 3, 4}, {5, 6, 7, 8}};

We can not omit everything even if we are supplying initializer, just the first square bracket may be empty. How about asking some questions? Start GDB session and ask all what you need to know:

(gdb) print &arr2d $1 = (int (*)[2][4]) 0x7fffffffe630 (gdb) print &arr2d[0] $2 = (int (*)[4]) 0x7fffffffe630 (gdb) print &arr2d[1] $3 = (int (*)[4]) 0x7fffffffe640 (gdb) print *arr2d $4 = {1, 2, 3, 4} (gdb) x 0x7fffffffe640 0x7fffffffe640: 0x00000005 (gdb) print **arr2d $5 = 1 (gdb) print **arr2d+1 $6 = 2 (gdb) print **(arr2d+1) $7 = 5 (gdb) print *(*arr2d+1) $8 = 2

Simple as that. There is one more question left, what will happen with double pointer initialized to address of array, why it not working? Again we are agile and write code:

int arr2d[][4] = {{1, 2, 3, 4}, {5, 6, 7, 8}}; int **p = arr2d; printf("*p = %d \n", *p);

That will execute and print *p = 1?! Start GDB session and check what is happening:

(gdb) p **p Cannot access memory at address 0x200000001 (gdb) p *p $1 = (int *) 0x200000001 (gdb) p sizeof(*p) $2 = 8 (gdb) p p $3 = (int **) 0x7fffffffe6e0 (gdb) x 0x7fffffffe6e0 0x7fffffffe6e0: 0x00000001 (gdb) x 0x7fffffffe6e4 0x7fffffffe6e4: 0x00000002 (gdb) x 0x7fffffffe6e8 0x7fffffffe6e8: 0x00000003 (gdb) p **arr2d $4 = 1 (gdb) p *arr2d $5 = {1, 2, 3, 4} (gdb) p sizeof(*arr2d) $6 = 16

Abbreviated print is p and x will print content of memory at some address. Array is not just pointer, there is size of it what counts. If we have used ld format in printf, we would see slightly bigger output than just one ;-)
That would be such lovely question for test, what would be output if we replace %d with %ld? Naturally it will be *p = 8589934593!
Ask yourself stupid questions for fun and for profit.