Debugging reserved names

[ereisch]

I'm encountering a problem in the idb debugger (version 12.0) where I cannot debug certain variables, which I'm presuming are reserved words to the debugger. In my program, I have a structure that has several thousand variables, one of which is a string array with the name "TYPE":
CHARACTER TYPE*7

When I try to examine this variable in the debugger, I get the following:

(idb) p OBJECT(1).TYPE
Unable to parse input as legal command or Fortran expression.

Is this a bug in idb or expected behavior?

Thanks

[Steven_L_Intel1]

I will let someone else with more familiarity with idb comment on the behavior, but will note that the Fortran language does not have "reserved names".

[ereisch]

Any updates?

Thanks.

[Ron_Green]

I'll need to put together a simple reproducer and get a bug report started. Since Fortran does not have reserved names, neither should a debugger with Fortran support. Not exactly good coding practice to use keywords in this manner, still, it should be accepted by the debugger.

I'll post the bug ID here along with my simplified reproducer.

ron

[mecej4]

Here is a reproducer.

[fortran]program tobj
implicit none

type objtyp
   integer :: i
   character(len=3) :: type
end type objtyp

type(objtyp) :: obj(5)
integer :: i

do i=1,5
  obj(i)%i=6-i
  obj(i)%type=char(64+i) // 'X' // char(70-i)
end do
write(*,10)(i,obj(i)%i,obj(i)%type,i=1,5)
10 format(1x,i2,2x,i3,2x,A)
end program tobj
[/fortran]

The problem occurs with the Windows version 10.1 of IDB in GUI mode, too.

Place a breakpoint on the WRITE statement, run, and display obj(2). Works fine.

Then try obj(2)%type (debugger command: p obj(2)%type). Does not work.

Change the component name from type, which is a keyword, to typ. Recompile and display obj(2)%typ; works fine.

[ereisch]

Thanks. Someone just brought another one to my attention. "print OBJECT.ID" returns the same result as typing "whatis OBJECT.ID".

Same instance as before, I have a large structure with hundreds of variables, the last of which is a character string defined as:

CHARACTER*32 ID

When you type "p OBJECT(1).ID", the debugger returns:

type = character*32

Expected return would be the contents of the character string.

[Ron_Green]

Original bug id is DPD200169064

my reproducer:

[fortran]program idbtest
implicit none

type debugthis
 integer :: answer
 character*7 :: type
 character*11 :: normalname
 real :: foo
end type debugthis

type ( debugthis ) myvar

myvar%answer = 42
myvar%type = "marvin"
myvar%normalname = "fordprefect"
myvar%foo = 3.1415

write(*,*) "The robot is ", myvar%type

end program idbtest[/fortran]

Setting the breakpoint at the WRITE, one can print myvar%normalname but not myvar%type. the IDB GUI can't display it either, expanding myvar fails to show %type but does show %normalname in expanded form.

[Ron_Green]

I appreciate the 2nd example. However, the mapping of Forum threads to bug ID has to be 1-1. I'll open an new thread with the ID bug.

This ID bug is unique enough that I doubt the fix for the first issue will fix this second issue.


Follow the ID discussion here http://software.intel.com/en-us/forums/showthread.php?t=82483
ron

[ereisch]

Is the status of a bug ID available on an externally-visible site, or is this something that is only available to Intel employees? I'm curious to see if this issue has been resolved in the more recent versions of the debugger.

Thanks

[Steven_L_Intel1]

It is not visible externally. That issue has not yet been resolved.

[ereisch]

Any updates on this issue (DPD200169064)?  I don't see any references to it in the release notes/fixes lists.

[Steven_L_Intel1]

It is unlikely that this will ever be fixed in idb, since, as noted in the release notes, idb has been deprecated and will likely be removed in a future release.We are working to enhance gdb's Fortran support and suggest you use that instead.

[Ron_Green]

although IDB has been deprecated, this IS fixed in the enhanced gdb we ship with our compiler, 'gdb-ia'.  Here is a screen session showing the fix:

$ gdb-ia

No symbol table is loaded.  Use the "file" command.
GNU gdb (GDB) 7.7-8.0.524
Copyright (C) 2013 Free Software Foundation, Inc; (C) 2013-2014 Intel Corp.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For information about how to find Technical Support, Product Updates,              
User Forums, FAQs, tips and tricks, and other support information, please visit:
<http://www.intel.com/software/products/support/>.For help, type "help".
Type "apropos word" to search for commands related to "word".


(gdb) file u270753

Reading symbols from u270753...done.

(gdb) break 18
Breakpoint 1 at 0x402d20: file u270753.f90, line 18.

(gdb) run
Starting program: /site/jf/cts1/quad/rwgreen/forums/u270753/u270753 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, idbtest () at u270753.f90:18
18	write(*,*) "The robot is ", myvar%type

(gdb) print myvar%type
$1 = 'marvin '


(gdb) quit
A debugging session is active.

	Inferior 1 [process 56679] will be killed.

Quit anyway? (y or n) y

[rwgreen@dpdmic09 u270753]$ cat u270753.f90 
program idbtest
implicit none

type debugthis
 integer :: answer
 character*7 :: type
 character*11 :: normalname
 real :: foo
end type debugthis

type ( debugthis ) myvar

myvar%answer = 42
myvar%type = "marvin"
myvar%normalname = "fordprefect"
myvar%foo = 3.1415

write(*,*) "The robot is ", myvar%type

end program idbtest