View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2923 Location: South Pole, Antarctica
|
Posted: Mon Sep 28, 2009 3:21 pm Post subject: Go from running to debug mode |
|
|
Please remind one handy command which allows you go back and forth from run to debug and back when you want it. Old FTN77 had it.
The most annoying and useless property of debugger always was its window "The application being debugged is running. Control will return to the debugger when either the breakpoint or error occur". It must have the option of returning control to the user when he wants to. Now though if you click on it, the code goes into binary mode which is well known to scare to death of ordinary people. |
|
Back to top |
|
 |
JohnHorspool
Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK
|
Posted: Mon Sep 28, 2009 5:25 pm Post subject: |
|
|
Quote: | Now though if you click on it, the code goes into binary mode |
Doesn't it do this when it pauses at a section of code which hasn't been compiled in debug mode. Dan, have you compiled all the code in debug mode? |
|
Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2923 Location: South Pole, Antarctica
|
Posted: Tue Sep 29, 2009 4:25 am Post subject: |
|
|
Yes, I know that. Things are that it not always works.
Here is example
Code: |
use clrwin
kRun=0
dowhile (kRun==0)
call temporary_yield@
call sleep1@(3.)
enddo
print*,'end'
end
|
|
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8210 Location: Salford, UK
|
Posted: Tue Sep 29, 2009 8:47 am Post subject: |
|
|
If you are debugging and stepping over a call like temporary_yield@ or sleep1@ (with a long time interval) then the processor will go away and do that and finish the task before you get a chance to break into the processor.
Break points correspond to machine instructions that have to be programmed into the assembly code. Library routines do not have these optional break points. Otherwise the library would be much larger and runtimes much longer.
In theory we could supply debug versions of our libraries but we would also have to distribute the code and that is not an option. However, you would still have the same problem when, for example, sleep1@ calls the Windows API sleep function. At that point you would need a disassembly of the Windows DLL. Suffice to say we have to be satisfied with what we have. |
|
Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2923 Location: South Pole, Antarctica
|
Posted: Wed Sep 30, 2009 8:56 pm Post subject: |
|
|
I hate this feature/bug all 20 years. It alone turned off probably 90 percents of potential FTN77/95 users (another factor of 10 was lost due to absolutely zero advertisement. Only that can explain why such excellent compiler was not known even in major fortran newsgroups)
I think the option should exist (and it must be default) never fall into assembler mode. It's a black hole. When you are there - you will not get out. In this example above the smarter debugger must know to avoid falling into library (or whatever program which does not have debugger information) and stop on fortran line with debugger information. |
|
Back to top |
|
 |
|