debugging - help

Hi,

I am programming in C.

( You know that __FILE__ is a 'macro' which may be used to print debug messages. )

3 questions :

a) I have 10000 functions in my project. I am interested in 100 of them. Whenever any of them are entered, I want a message printed saying the same. ( such as "function foo_bar entered." when entering foo_bar )

What is the least effort way of doing this ? I hate to edit the individual functions. They are too many.

b) Given a function address, can any compiler tricks be used to print the associated function name ( without manually putting the name in the source code ) ? ( I know that map file will give it, but i am looking for an automatic way of doing this at runtime itself. )

c) Any good website or book for info related to debugging code execution ??

thanks shankar

Reply to
kbc
Loading thread data ...

This is likely off-topic, because a solution would be implementation specific (like using a compiler switch to generate instrumentation code at the function entry/exit).

Reply to
xarax

You're making it hard to help you by not mentioning what your target platform is. Such hacks are highly platform-specific.

Get yourself a good debugger. Keep your fingers crossed that your target platform can handle 100 breakpoints simultaneously. Set a breakpoint at each of those 100 functions, instrumented to print that message. Run and watch.

Certainly not by _compiler_ tricks --- the compiler doesn't even know where the function's will eventually end up being located. Only the linker knows that.

The linker usually does offer a trick to achieve that: it's called "debug information". But none of that is usually available at run time, if only because debug info is invariably stripped off the image before you actually put into the embedded device.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Most of the Byte Craft compilers have a switch in them to emit break point information in the source level debug environment to track execution through the control path of the program (calls, jumps and conditionals). The execution information can be used to validate formal execution regression tests and track performance of the system and is compatible with testing methodology of McCabe and others.

By involving the debug environment in the reporting process there is no execution overhead and the instrumented code is the same object code that is shipped with the application.

Walter Banks Byte Craft Limited //http:

formatting link

kbc wrote:

Reply to
Walter Banks

If you are using gcc and gnu ld, then you can get ld to "wrap" all calls to a given function. You need to write an extra module that has the wrap functions (which would print out the function name or other information, then call the original function). It might be a bit tedious to write 100 wrap functions, but a couple of perl/python/awk scripts and/or a text editor with good keyboard macros can handle the donkey work.

An alternative might be to look at using profiling information to track function calls, assuming you have a compiler that supports profiling.

Reply to
David Brown

If i understand, you know what are these '100' functions. First of all, if you work with big project and have to debug it - use good Editor ( such as CodeWrite or MultiEdit ). So, you can use regular expressions and macro for inserting these printings.

Generally, as people already said, at runtime you don't know functions' names. Besides, here, you don't say that you want to do it when entering function, right ? So, without appropriate instrumentation tools, you cannot do it.

Did you search it on Internet ?

Reply to
Michael Str.

thanks for all replies.

i am executing on Armulator using AXD debugger.

What i have is an array of function pointers which get periodically filled up. I parse this array each time, calling the functions indexed by the pointer. I would like to print the name of the function before calling it.

I dont want to put breakpoints.

__FUNCTION__ will help only in printing from within the function.

shankar

Reply to
kbc

Ah! Now that's a whole different situation than what your original description sounded like. The trick is simple, in this case: make that array store (pointers to) structures with two elements: the function pointer and the name of the function itself. Both can easily be generated in a single mention of the function name by use of the preprocessor:

typedef struct named_function { func_ptr p; const char *name; } named_function;

#define TABLE_ENTRY(name) { name, #name }

named_function action_table[] = { TABLE_ENTRY(func1), TABLE_ENTRY(func2) };

Now all you have to do is print action_table[i].name just before you call the function action_table[i].p.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

i have no access to the entity which is filling the array. so your method will not work. ( But i can edit the parser function which calls the functions pointed by array-elements. )

i guess what i need is a content-addressable array to get the index given the function address. then i can use that index to print the function name from another array. dont know how to do it.

Reply to
kbc

But there's a global table of functions *somewhere* that lists all functions by name that this "entity" is allowed to put into the array, right? There really should be, if only to allow a test that there's no utter nonsense put into the command array.

If that exists, you still are left with two possibilities: automatically generate wrapper functions for all those functions that just print the name of the function about to be called, then call it. Then put those wrappers in the action table, not the actual functions themselves.

Just use a (pointer + stringified name) table like the one I proposed, sort it by function pointer, and binary-search through it.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.