I just fired up totalview on my "hello world" application (c++) and i only get to view the assembly code.
Is there any settings/flags i need to set to view the source code? Menubar->View->Source As->Source does not work for me.
the application im trying to debug is just a cout << "Hello World" application, just to get the debugger up and running.
Lets start with the simple stuff.
Did you compile your application with the '-g' debugging flag? The debugger relies on the compiler to provide it with a symbol table and line number table to map what happens in the executable back to your source code. Without that -g flag (or if you subsequently strip your application) that info won't be present and assembly debugging is the best you can hope for.
If you did compile with -g are the source and the executable all together in the same directory, or if not have they been moved since you compiled them? The compiler only knows the locations of the source and executable at the time they are created, if you move them around then sometimes the debugger won't be able to locate the source code file. In that case you might need to give it some help by defining a source code search path.
Write back here and let me know if -g fixed your problem. If not we can look into the search path and such.
Cheers, Chris
I realize that Jason94 has almost certainly solved his problem some other way, but I figured I could chime in here to answer this since it is a good question.
For this particular case it would be interesting to know if the program is multi-threaded. TotalView is designed to let you work with multi-threaded programs and it has a characteristic that may be surprising to users. By default it won't always focus you on the thread that hits the breakpoint. So your program might actually have stopped at your second breakpoint in another thread.
Imagine you have 6 threads (we'll number them 0 - 5) and you set a breakpoint in a routine. Thread 0 is the one you are focused on and you hit "go". The program runs and thread 4 hits the breakpoint first. By default the breakpoint will stop the whole process when the breakpoint is hit. In the debugger you might see assembly representing where thread 0 was when thread 4 hit the breakpoint. You can check the root window or the thread pane to see what the status of the other threads are and you might see that one of them says "B2" (for breakpoint 2). Then you can click on that thread and TotalView will refocus you to that thread and you'll see it sitting at the breakpoint.
Why do we do that? Well, because we think it is confusing/disconcerting to have your focus "ripped away from you" just because another thread hit a breakpoint. So by default we leave the user in control of their thread focus.
There is a preference that you can change which will tell totalview to refocus the process window to the "site of the event". You can set that if you would prefer to have TotalView refocus your attention to the breakpoint, but be aware that as you do that you may be bouncing from one thread to the next.
The other possibility is that TotalView stopped the process for some reason other than a breakpoint being hit. Did the program segfault? Check the status bar at the top of the process window to see what the status of the thread and process are.
Anyway -- just wanted to post this for the record.
