Gospel code

#!/bin/bash
echo "Testing module link.c with gcc -g option for gdb and kdbg"
gcc -g -o link link.c
if [ $? == 0 ]
        then
 objdump -d -M intel link >link.dsm
 echo "Compile and link OK, running mtrace, ltrace, strace"
 mtrace ./link &> mtrace.txt
 ltrace ./link &> ltrace.txt
 strace ./link &> strace.txt
 
 echo "Press y and -enter- to use kdbg on the code"
 read d
 if [ $d == "y" ]
                then
  kdbg -t kdbg2gdb.txt link
 fi
 
else
echo "Check your code, Frodo, I think you made a misteak[sic]."
fi

Gospel code is fairly difficult to make and requires a lot of analysis. It might seem very odd and time consuming to some to take the code generated by gcc and decompile it and also run gdb and other utilities on the code when there are no errors to check for. It is in the process of digging through all that, where I am able to look at each critical function and wonder upon what is really happening, can it be exploited, is it solid, what errors would happen under odd conditions, what time is involved, how does it affect other things.

console2# xtrace -D:9 -d:0 -k -o Xtracefile.txt
console1# link -display :9.0

The output files are analyzed by another part of the program that sorts through and separates the traces to generate a structured report which is viewed inside the program. There are many things that are very bad that a person can get away with in "C" or any other language. Since you are controlling the hardware in a sense, you can do some very bizarre things. Even with years of experience programming, it is possible to create things so complex that they defy direct analysis with anything other than stochastic methods. That is why the core code must be rock solid.

I am studying several openGL debuggers and I may have to devise my own code as the general debuggers are nice, but they last the detail analysis that I desire.

These traces become quite convolved with the additional of even a small level of complexity. Just the act of opening a GL context adds a dozen pages of trace into X and libraries. I think I am using mtrace incorrectly also and this is part of debugging, debugging the debugging tools.

ADDED: I was using mtrace incorrectly and it is quite a bit more involved that a simple utility. When using openGL and drivers it allocates memory continuously and this is never released in the program as it is static locations ( my guess), I think that will take some time to resolve. I will take quite a bit of external manipulation of logs to sift to what I am interested in.

ADDED MORE: I also added SIGSEGV support in the code. This should allow some analysis, should the machine fault.