Topic: Questions on debugger and code optimization

I have made significant progress in converting my simulation code over to the SF/GNU FORTRAN. However, I have reached a point (after much poking/hacking around) where I am stuck. Two things plague me right now and I am not sure how to proceed.

During testing of the many options in my code I noticed that things behaved strangely. Upon debugging, it appears as though the spaghetti code (which I use to initialize my system variables though all the possible options) has selective lines of code optimized out (which you might imagine are there for a reason). While trying to understand what and why this might be happening and to which lines of code, the debugger has stopped working, at least the way it was before.

I can't really proceed until I can get the debugger working to tell me which lines of code are affected by the optimizer. I also need to know if there is a compiler directive that I can select areas of code not to be optimized. I have looked for this option but don't see anything.

However the debugger is my immediate problem. When I open it up, all seems normal. I open the executable to be debugged and then it opens the code in the window for a brief second (as what was normal before) but then goes blank with the following message:

"Select function name to disassemble"

I can reopen the code again, but can't step into anything or run to break points. I know I must be doing something really stupid but I can't seem to get it doing what it was before. I will freely admit, I have little understanding of how a real programmer would use these tools but it is similar to the MS FORTRAN debug tool that I have used.

Thanks for your help.
Rod

  • jeff
  • Administrator
  • Offline

Re: Questions on debugger and code optimization

Rod,

Have you tried disabling all optimization first?  The compiler shouldn't perform any optimization unless directed to do so.  The symptoms you're describing seem to suggest that debugging was disabled at compile time.  If you've been playing with compiler options, it is usually advisable to clean the project after making any sort of change. 

What architecture are you compiling for, 32- or 64-bit?  If you are on 64-bit Windows, I might also suggest trying both 32- and 64-bit builds to see if there is any difference.

If you continue to have issues, you can email your Makefile to me at support@approximatrix.com for me to examine to see if I can sort out if a compiler option is causing the issue with the debugger. 

Sorry for the issue.

Jeff Armstrong
Approximatrix, LLC

Re: Questions on debugger and code optimization

Jeff,

Thanks for the quick response. Here is some more information.

As far as optimization, I do disable optimization and when I do, things behave better (not perfect as there may be coding issues that I need to debug). It is when I set the -O2 option in the build step that things go really weird and I notice that lines of code get optimized out.

Debugging is enabled during the compile and build step. I am compiling for 32 bit executable for now but my workstation platform is 64 bit. When building, I always do the clean step.

I didn't think to look at the Makefile for issues but I probably wouldn't understand what those issue would be anyway. I will check that out tonight when I get home from work. If needed, I will send the makefile to you then.

Another issue I am having is the launch button. How do I configure that to launch the program. I have the default directory set but it can't seem to find the executable to use. Do I enter the executable name into the above command line options text box(I've done that but it makes no difference)? What goes in there exactly? LOL!

Thanks again for your help.

Rod

  • jeff
  • Administrator
  • Offline

Re: Questions on debugger and code optimization

Rod,

Conceptually, I would guess that some lines could be "optimized out" when any sort of optimization is enabled.  When I'm debugging, I do indeed try to avoid enabling any optimization. 

The launch button is automatically and internally configured to launch the target program (as defined in Project Options).  Command line arguments would be to add any arguments you wish to pass to your program, and it should not contain the executable name itself.  The working directory can usually be left blank, which indicates the program should run in the directory in which it was compiled.  If the launch button isn't working, something else is quite wrong.  If that's the case, you can email me your project file (ending in ".prj") and Makefile to troubleshoot the issue.

What version of Simply Fortran are you working with?  I just want to make sure that you're running the most up-to-date version.  Also, what is the name of your target program and in what directory are you working?  Some tools can have issues with paths containing spaces or parentheses.

Jeff Armstrong
Approximatrix, LLC

Re: Questions on debugger and code optimization

Jeff,

I downloaded the SF image this month, just a few weeks ago. I think I am using 1.37? My first post to the forum was on 1/14 and 1.38 was release on 1/14, so probably I am using 1.37. Does that sound right? I will send you some of the asked for information when I get home tonight.

Rod

Re: Questions on debugger and code optimization

Jeff

As per email to the support group, I sent PRJ and MAKEFILE files to you. I also downloaded the latest version, 1.38 and installed it.

I am able to debug now it seems but still behaves oddly. It will also crash if I restart it several times, which is not a big deal.

Suggestions to limit my debug to single threaded code make a lot of sense and I will try do that going forward.

Rod

Re: Questions on debugger and code optimization

'Grogley wrote,

-----------
...the debugger is my immediate problem. When I open it up, all seems normal. I open the executable to be debugged and then it opens the code in the window for a brief second (as what was normal before) but then goes blank with the following message:

"Select function name to disassemble"
I can reopen the code again, but can't step into anything or run to break points.
-----------

I have been having exactly the same problem for some weeks, with one of my projects.
I can set breakpoints OK but when I try to run, the debugger emits exactly the same error message as above and then operates exactly as Grogley has described..
I've switched back to the old way of debugging, by inserting print statements.  So slow.

I am compiling on a 64bit laptop for 32bit code.
No optimisation is set.
----
John

  • jeff
  • Administrator
  • Offline

Re: Questions on debugger and code optimization

Rod,

I just posted a bug about your Launch button issues.  I'll look into a new build of the debugger.  Let us know how restricting debugging to a single thread works out too.

Jeff Armstrong
Approximatrix, LLC

Re: Questions on debugger and code optimization

Jeff,

I made the changes you suggested to the launch configuration and that workaround does the trick. Is the debugger supposed to use the same command line options put in the launch section?

I am able to debug now. One trick I discovered is after you open the debugger and launch the executable, if you click the icon for going to the next debug break point, then the debugger does start doing what is intended and you can step into and out of and through the next code lines as intended. Perhaps John can try that too to get it working.

Debugging an OpenMP code with a single thread is probably the way to go. However, the debugger will not step into an OpenMP directive set of code. I am not sure if it should but it would be nice.

Now I have to figure what my crazy code is doing...

Rod

10 Reply by JohnWasilewski (edited by JohnWasilewski 2013-01-26 12:45:13)

Re: Questions on debugger and code optimization

Rod's trick,

after you open the debugger and launch the executable, if you click the icon for going to the next debug break point, then the debugger does start doing what is intended and you can step into and out of and through the next code lines as intended,

...doesn't work for me.

I do this:
- open the debugger using the debug icon,
- check correct breakpoints still set,
- launch, using the 'Run (R)' icon.

I do not get the chance after this to click the next debug break point icon, 'Next (R)', in the way that Rod has been able to do, because the display panel blanks half a second after I press the 'Run (R)' icon, with the 'Select function name' error message at the top:

'Select function name to disassemble'.

All debugger icons are active but the the 'Next (R)' icon just flashes the icons panel fractionally and returns to the same blank panel with the same error message.  I've tried holding my finger on the 'N' key to hammer it with repeats of the same command.  Same result.

I've also tried running the Insight debugger executable manually, not running it from within SF.
I've tried it with both the 64-bit and 32-bit versions (my executable is built on a 64-bit laptop, as 32-bit code).
Same result both times.

One final clue I've noticed:
After running the debugger, before launching the application, the selector at the far RHS of the display is set to 'SOURCE'.
When the error occurs, it has changed to 'ASSEMBLY', and will not allow me to re-select 'SOURCE'.
---
John

  • jeff
  • Administrator
  • Offline

Re: Questions on debugger and code optimization

John,

I'll start looking into the debugger issues.  I can't say what's wrong right off the top of my head.  Would you mind emailing me your makefile just so I can have a look?

Jeff Armstrong
Approximatrix, LLC

Re: Questions on debugger and code optimization

I just wanted to chime in that the debugger seems to be working for me as intended. The "trick" I was using before is no longer needed. I am somewhat baffled as to why. I may have had break points set wrong or not active or not in the execution path.

The one thing I did change is that under project options, I have only the executable name in the "Target Name" dialog. Jeff had me remove the full path name to the executable. Since then, things are working.

The other thing that is different is that I did download version 1.38 and install it. It could be that I registered the product last night, LOL.

Thanks again for all the help.

Rod

Re: Questions on debugger and code optimization

I'm using 1.38.
My executable name is set to   InStruct117(32bit).exe
without a pathname.
Insight is still not working for me.
---
John

  • jeff
  • Administrator
  • Offline

Re: Questions on debugger and code optimization

John,

One thing I would suggest is changing your target name to something without parentheses.  A good number of GNU tools do not play well with parentheses in path names, and Insight is probably not happy about the executable's name.  I would alternatively suggest using the name "InStruct117-32bit.exe" and trying Insight again.

Jeff Armstrong
Approximatrix, LLC

Re: Questions on debugger and code optimization

I've tried that.
Same result.
I am able to debug some of my projects with Insight.
Just not the ones I'm working on, worse luck!
---
John

  • jeff
  • Administrator
  • Offline

Re: Questions on debugger and code optimization

Version 1.39, which is currently undergoing testing, includes a new version of Insight.  Hopefully the update will fix any issues that Insight users are experiencing.

Jeff Armstrong
Approximatrix, LLC