Incorrect first line of subroutines in debugger under /64

If you want to go to some specific subroutine in debugger, you just Ctrl+F the name of subroutine and you are there. In 32 bit this works fine but the 64bit fails to step in right first line.

To reproduce this annoying bug follow these steps: compile PROG with /debug /64, start program in debugger SDBG PROG.EXE, put the name PROCESSOR_ID in CTRL+F window and hit ENTER. The SDBG will step on wrong line (second or third instead of first) Here is the demo use mswin Integer, external :: processor_id jj= processor_id () end !--------------------------------

      integer function processor_id () 
! 
!       With thanks to John Horspool 2008-04-02 
! 
   use mswin 
   CHARACTER*400 LDATA 
   CHARACTER*80 getenv@, IDENTIFIER 
   CHARACTER*80 CPU_stepping, CPU_description
   integer   n_processorsTotalGetEnv
   character*256 ResultsToSave(10)
   integer iVersionOfTesrResFile

        LSTR=400 

        k = REGOPENKEYEX(HKEY_LOCAL_MACHINE, & 
         'HARDWARE\DESCRIPTION\System\CentralProcessor\0', 0,KEY_READ,MyKey) 

   CPU_description= ' N/A ' 
        if (MyKey.GT.0) then 
          k = REGQUERYVALUEEX(MyKey,'ProcessorNameString', & 
              CORE4(0),CORE4(0),LDATA,LSTR) 
!          WRITE(*,'(a,a)')' Processor : ', LDATA(1:LSTR) 
     CPU_description = LDATA(1:min(80,LSTR)) 
        endif 

   k = REGCLOSEKEY(MyKey) 

!   write(*,*) getenv@('PROCESSOR_IDENTIFIER')    
!   write(*,*) 'Number of cores=', getenv@('NUMBER_OF_PROCESSORS') 

       READ(getenv@('NUMBER_OF_PROCESSORS'),*)n_processorsTotalGetEnv 
       Write (*,*) ' Number of Processors/cores/threads= ', & 
       n_processorsTotalGetEnv, ' ', getenv@('PROCESSOR_IDENTIFIER') 
       Read (getenv@('PROCESSOR_IDENTIFIER'),'(a)') CPU_stepping 

   processor_id=2 
        end function    

Thank you for this observation

I remember, this has been already observed in a previous email concerning sdbg64. Here another short example named sample2.for:

      INTEGER*2 plus
      INTEGER*2 a,b,res
      a=1
      b=2
      res=plus(a,b)
      write(*,*) 'a=',a,'b=',b,'res=',res
      stop
      end
      function plus(x,y)
      integer*2 x,y
      integer*2 plus
      plus=x+y
      return
      end

Build it via

ftn95 sample2.for /debug /64 /link

and start sdbg64 sample2.exe. Now pressing CTRL-F and then entering plus to the 'Find Routine' window shows line number 12 in the 'Find window'. However, confirming the find window (via CR e.g.), sdbg64 positions to line 13 (and makes it grey).

Regards, Dietmar

Dan,

I do not get your SDBG problem, but the code example is very interesting.

I would have thought that the following line of code is asking for trouble. READ(getenv@('NUMBER_OF_PROCESSORS'),*)n_processorsTotalGetEnv

I replaced it with : IDENTIFIER = getenv@('NUMBER_OF_PROCESSORS') READ(IDENTIFIER,*)n_processorsTotalGetEnv

I then proceeded to start reading information from the registry, which is very interesting.

I also maintain an environment variable which is the FTN95 version number, which can be retrieved with getenv@('FTN95_Ver')

I shall look more closely at SDBG64 and see what is happening. Thanks for the example,

John

Pity that people rarely use the debugger. And the developers do not use their compiler for anything too (teaching, consulting work, doing simulation job etc). This is clear by this example which has tons of bugs in 64bit regime and no one reported them while i do that third time already

A=1; B=2; C=3; D=0

If(A.lt.B.and.B.lt.C) D=4

Print*, 'D=',D
END

In 32bits debugger works OK. But compiled with /64 and using sdbg64 we get:

1. SDBG64 does not show value of B or C if you hover with the mouse over B or C (in the popup window)

2. Instead it shows the result of logical operation which would be great if it still somehow showed B and C too, not instead. And if it showed the result of logical operation correctly (the result should be TRUE obviously).

3. If you hover over A, B or C more than ones in sequence, second time this does not show the value. To see the value again, you need to hover your mouse over something else

There are also other problems with SDBG64 i will describe later. One is extremely annoying, all were reported too and some we already tried to resolve but i had no time to complete it.

Dietmar, John, thanks, will look at your examples and modifications when will have time

Even the 32 big SDBG has a number of quirks.

If you take Dan's example and place the mouse pointer on the 'D' preceding '=' in the PRINT statement, you will see the value of the variable D displayed. SDBG seems to regard part of a (properly quoted) string as a variable.

On the line with the IF statement, with the mouse pointer on 'A', you will see the value of A. With the pointer on the 'B' after '.lt.', you will see the value of the expression A.lt.B instead of the value of just B. If you next move the mouse pointer to the second 'B' on the same line, SDBG will attempt to show you its idea of the value of the expression A.lt.B.and.B, which is nonsense. B is not a logical variable and the AND operator cannot be applied to it.

If you want to be surprised even more, use the following modification of Dan's program. I have just renamed the variables, noting that Fortran keywords are not reserved. The code is legal but certainly not well-formed.

LT=1; IF=2; AND=3; PRINT=0
If(LT.lt.IF.and.IF.lt.AND) PRINT=4
Print *, 'D=',PRINT
END

Place the mouse on the keywords If and Print (not the variables with the same names) and you will see the variable values displayed.