LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Tread Tracing

Need help to get the tread id and function caller for run-time debugging.

Ex. Which function called logstate() and the tread ID. The logstate() needs to extract the caller and retrieve the tread.
0 Kudos
Message 1 of 4
(3,259 Views)
Hi abui,

you can get the thread ID by using this function: CmtGetCurrentThreadId().

As for function, i'm not too sure if you can get that information. Maybe others may know.

Hope this helps.


Regards
AL
0 Kudos
Message 2 of 4
(3,251 Views)
I too don't know how to retrieve the caller of a function. In this case I simply would add a parameter to the called function and pass __FUNCTION__ macro to the called one.

That is:

Defining a function:
ThisIsMyFunction (......, char *func)
{
...
...
DebugPrintf ("%s: my caller was %s\n", __FUNCTION__, func);
}


Calling the function:
{
...
...
ThisIsMyFunction (......, __FUNCTION__);

}


Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
Message 3 of 4
(3,242 Views)
Well,
(Keeping an eye on my flak jacket)...

If all of these assumptions are true:
-you want to--or have to--stay out of the CVI debugger
-you don't have to automate this (and don't mind putting pencil and paper to it)
-you have a valid MAP file for the executable, from whatever compiler made the EXE/DLL
-you run an NT descendant (2K, XP, 2K3, etc.) on Intel silicon

Then you can use tools similar to Microsoft's WinDbg to reverse engineer some of this. The address of the parent function that called your target function may be sitting in EBX the moment your target function first starts to run. I know this to be true in certain situations, but I can't definitively say what situations might make it false. Maybe not with hyperthreaded CPUs. You should be able to single-step through WinDbg and watch as any nested function calls return. I would rather go to the dentist than do that all day. You would probably need a good reference book for WinDbg too, because it is faily un-intuitive.

You can find all of what you want through the CVI debugger, even across multiple threads, if you debug it live. If you have the source code, can't you feed yourself hints about the program flow and timing by adding messages to the CVI debug output window (like stdout)? What about doing the same with a text file or a database? I don't know of anything native to CVI that will help you get the parent functions in an automated (programmatic) fashion. I've heard that C++/NET can do it, since they have stack dumping functions....

Orlan
0 Kudos
Message 4 of 4
(3,237 Views)