Link to home
Create AccountLog in
Avatar of phoffric

asked on

Need trace of user methods called when running Qt Creator 2.6.0 based on Qt 4.8.2 with g++ 4.4.7 or MS Visual Studio 2010

Using Qt Creator 2.6.0 based on Qt 4.8.2 with g++ 4.4.7 or MS Visual Studio 2010.

Was given project consisting of dozens of classes each containing many methods.

I do not want to put in break points in every method to find out which methods are called - too many methods.  Is there any way to get the QT compiled code to generate a log of the methods called while running the program?

Note that updating programs or compiler is not allowed so I am stuck with what I have.
Avatar of sarabande
Flag of Luxembourg image

imo there is no log of the current stack.

to show call hierarchy into the output window of the IDE you might add

qDebug() << "begin " << __FUNCTION__ << "\n";

at begin of each function


qDebug() << "end " << __FUNCTION__ << "\n";

at each return.

this can easily made more comfortable by defining macros.

#define BEG_FUNC qDebug() << "begin " << __FUNCTION__ << "\n";

in a global header file. it is also possible to indent the function names properly if you want.

note the qDebug() would do nothing in release build. so you could use the macros both in debug or release.

Avatar of phoffric


In some previous projects, I've done those ENTER/EXIT messages before for specific functions. But I am looking for a trace of functions for the entire program as they are called without having to modify any code. I just hit the green Debug run button, and hope to get a trace.

Hopefully, there is a way to do this by setting up some compiler configuration.
Keep in mind that I would rather not do the code modification that you suggest for 1000+ methods. I would not be allowed to include that in my code base, so in the end, I would have to remove them. I am just trying to navigate my way around 22K+ LOCs.
I have updated the question with the correct version numbers:
Qt Creator 2.6.0 based on Qt 4.8.2 with g++ 4.4.7.
i recently worked in huge project with millions of lines of code. we used macros at the begin and end of functions (non-trivial functions only) in order to get a trace and to implement a try-catch for each function. this was done over decades but adding those macros for new code is no efforts. actually it is also not very difficult to write a little tool which adds those macros to existing code. of course you might need a few of  persuading what might be easier if you can show a sample project where it already worked and where the advantages can be seen.

I recall in the past that I was able to get a function trace without having to modify the code base. I just started a new job and do not want to persuade the lead to do this.

I am looking for a qt creator method to do this without having to change the code.
With the constraints you face, you have to go for gdb breakpoints: there is no other way.
Given your assignment, I would go for a specialised expect script to drive gdb, using as a start point my generalised gdb expect script "ggo". ggo feeds gdb breakpoint and other commands from its command line, but would not be appropriate for literally thousands of breakpoints. The specialised script would set the breakpoints from a list of functions that you'll have to come up with. On hitting a breakpoint, the script reports the function being entered and sends gdb a fin command. On hitting a fin termintaion, the script reports the function being returned from and issues another fin command.

Have you tried using Qt debug mode? Or is this not a option for you?
>>  you have to go for gdb breakpoints: there is no other way.
Ok, you are saying that "it cannot be done". I will try to find a mechanism to do this without modifying the existing code or using breakpoints. I think I found a Linux lead yesterday, but will need to find some time next week to see if it does the job. (I cannot always get on a Linux workstation - have to borrow one when the owner has logged out for the day.)

>>Have you tried using Qt debug mode? Or is this not a option for you?
I am guessing that you are suggesting that I put in breakpoints in the hundreds of methods.

From the OP:
I do not want to put in break points in every method to find out which methods are called - too many methods.
BTW, I thought I saw that gdb allows regex in setting breakpoints, so that if all the methods began with XYZ, then I could set a breakpoint on all the methods beginning with XYZ in one command. That would have been half way acceptable. At least I could keep hitting "go" and get a list that way. Ideally, with breakpoints, I would want a "continue" in the action on hitting the breakpoint so that I wouldn't have to keep going manually.

But the legacy project that I am looking at does not have any universal pattern in naming methods.
It may be possible to use the built in debugging helpers they have 200 or more built in.
Qt Creator ships with debugging helpers for more than 200 of the most popular Qt classes, standard C++ containers, and smart pointers, covering the usual needs of a C++ application developer out-of-the-box.
If you could be more specific in using debugging helpers as to how to solve my question, i would appreciate that.

I am not interested in examining Qt classes or standard C++ container, or smart pointers usage. The only thing I am interested in is seeing what programmer defined methods are called when I start the program and let it run for a few seconds. Right now, it is hard for me to know what are is being called and the order they are called in once the GUI is displayed.

There are 1000's of Qt SIGNALS and SLOTS connections, so a manual trace is very difficult for the 1000 methods.
>> imo there is no log of the current stack.
Not absolutely positive of what you are referring to, but if you are saying that "the OP goal can't be done", then I have found a way to accomplish this goal.

>> qDebug() << "begin " << __FUNCTION__ << "\n";  at begin of each function
Violates the terms of the OP:
      "Note that updating programs or compiler is not allowed"
>> you have to go for gdb breakpoints: there is no other way.
>> Have you tried using Qt debug mode?
Violates the terms of the OP:
      "I do not want to put in break points in every method to find out which methods are called - too many methods."
Avatar of phoffric

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Looks good! Will you be accepting your post as the solution?
What I am doing now is just running the program under certain GUI operations, and then looking at the calling sequence after the program completes.

Alternatively, I think I can keep the program running continuously. I believe I could customize the two enter/exit functions to send the results to another program which transforms the results into a user-friendly active display as I am running the program.

Since the program is a simulation, I would probably have to set the Time Step to an artificially long period, say 20-60 seconds, to give me a chance to review the calling sequence depending upon what GUI buttons/text entries I would make.

I didn't really understand your post and was going to discuss it with you when I discovered the -finstrument-functions compiler option, and pursued that approach. I have limited time at work to try things since they kick me out way too soon compared to everywhere else I worked - well, rules are rules :( :( .

If your approach satisfies the OP constraints, then I'd like to talk to you about it. I am on a crushing development effort at the moment to demonstrate that the lead's Model Description Document is sufficiently well-written that I can actually write a model from it; and I promised not to look at his model/code (which is the source of this question), so this effort is on hold for a little bit until I finish that section.

But I would like to understand what you were driving at in the next couple of weeks, if that's OK with you. I won't have time at work, but on a free weekend, I could come up with a toy foo/bar example and see what you are talking about.
Fine, look forward to that,

Cheers ... Duncan.
This appears to answer the Q and EE wants the Q closed.
phoffric - you can still post to this Q after it is closed (e.g. to pursue the expect path)