forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incorrect first line of subroutines in debugger under /64

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2108
Location: South Pole, Antarctica

PostPosted: Tue Jun 04, 2019 3:16 pm    Post subject: Incorrect first line of subroutines in debugger under /64 Reply with quote

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
Code:
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   


Last edited by DanRRight on Fri Jun 07, 2019 6:35 pm; edited 2 times in total
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 277
Location: Manchester

PostPosted: Wed Jun 05, 2019 12:05 am    Post subject: Reply with quote

Thank you for this observation
Back to top
View user's profile Send private message Visit poster's website
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 179

PostPosted: Wed Jun 05, 2019 2:06 pm    Post subject: Reply with quote

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

      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
Code:

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
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2144
Location: Sydney

PostPosted: Fri Jun 07, 2019 2:50 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2108
Location: South Pole, Antarctica

PostPosted: Fri Jun 07, 2019 6:21 pm    Post subject: Reply with quote

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

Code:

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1202

PostPosted: Fri Jun 07, 2019 7:10 pm    Post subject: Reply with quote

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.
Code:
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.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1227
Location: Aerospace Valley

PostPosted: Sat Sep 07, 2019 4:38 pm    Post subject: Reply with quote

Dan wrote:-
Quote:
Pity that people rarely use the debugger.


This is so true.

I think the glitches highlihted on this post are an excellent example because if people did use it more often there would have been more glitch reports and things would have no doubt alreaduìy been ironed out.

As for the glitches themselves this must be linked to how the debuger tracks the mouse cursor and as a result which variable value it picks up rather than the variable values themselves somehow being in error (I hope).

I alsìways remain amazed how you guys pick up some of these glitches.
My hat tips to you.

Even more tipping of the titfa is in order for the way you take the time to report even the most minor of glitches - many people no doubt would just ignore a 'wrong' value popping up as they dragged the mouse and left it over a variable for a fraction too long.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group