Detecting runtime problems.

Daniel Myers peirthies1 at
Wed Apr 16 10:00:15 PDT 2008

The best route that I can think of to get you going, is to write a stub.
A stub basically simulates the system that you are trying to integrate 
with but don't have access and can allow you to debug your own code.  
Here is a wiki page on it giving a more general idea:
basically you write a small program that gives back a specific data that 
is static that allows you to debug your own software.  Stubs are used 
quite frequently on large projects where not everyone gets their code 
done in time for others to start debugging, or limited times to run the 
test code on the actual system.
Hope that helps

JonY wrote:
> Hi lfs-chat,
> I'm new to C programing. I'm trying to develope a program for a TI c6711 
> board but do not have enough access time to it to test for various 
> runtime conditions and problems.
> My project is an infix syntax calculator with working keypad and LCD 
> which is to be done under 6 hours of access time.
> The bulk of the backend (includes memory allocation and string 
> processing) code is already working. It is developed seperately and is 
> already tested with gdb and mpatrol. The frontend (keypad interrupts and 
> LCD interface) which can't run on the host machine needs more error 
> detection and handling codes and generally, more testing.
> My current method of debuging the frontend without access to a test 
> board is to go through the code line by line and writing down variable 
> names and value changes on paper.
> Is this good idea, or are there more efficient debugging methods? If 
> not, any programming advice?
> Thanks.

More information about the lfs-chat mailing list