problem setting displays

problem setting displays

[Arjan van Dijk]

Hi,

In a regular gdb 5.2.1 session on a Dec Alpha running the C-shell in TRUE64
Compaq unix and also in a gdb 5.0rh-15 session on my Linux RedHat 7.2 box
running the bash, I don't seem to understand how to set permanent watches
via the 'display' command. Can someone help me with the following example.
Here are two fortran files, which really do nothing harmfull or difficult:


########### file test.f runs from here ##################
      PROGRAM Test
      INTEGER i,j,k
      REAL x

      CALL MakeFun

      DO i=1,100
        x = REAL(i)
        IF (i.EQ.10) THEN
          x = x+1.
          WRITE(*,*) 'Joehoe!'
        ENDIF
      ENDDO
      END

      INCLUDE 'test2.f'
######## to here and file test2.f from here ##############
      SUBROUTINE MakeFun
      INTEGER i
      i = 5
      WRITE(*,*) 'Have fun!',i
      END
################### to here ##############################

I compiled the program with the gnu fortran compiler via:

g77 -g test.f -o test.exe

The resulting executable runs ok, and prints:

 Have fun! 5
 Joehoe!

Then I started gdb 5.2.1 on a Dec Alpha machine (at home gdb 5.0rh-15 on
RedHat 7.2 it gives more or less the same session, see below) via:

gdb -q -f

The following session took place. First I load test.exe, set a breakpoint
and a watch, run the executable and let it continue after it halted at the
breakpoint. Keep in mind that even though the ctags program suggests that
we have a main program body named "Test" (as I think it should, since I
called it that), the g77 compiler has renamed it to "MAIN__" (and in the
f2c-phase annoyingly added an underscore to all routine- and function
names):

##### (gdb) file test.exe
##### Reading symbols from test.exe...done.
##### (gdb) break test.f:9
##### Breakpoint 1 at 0x120001900: file test.f, line 9.
##### (gdb) display MAIN__::i
##### (gdb) run
##### Starting program: /home/mfo/vndijk/.neditutil/test.exe
##### Have fun! 5
#####
##### Breakpoint 1, MAIN__ () at test.f:9
#####/home/mfo/vndijk/.neditutil/test.f:9:122:beg:0x120001900
##### 1: MAIN__::i = 1
##### Current language: auto; currently fortran
##### (gdb) continue
##### Continuing.
#####
##### Breakpoint 1, MAIN__ () at test.f:9
#####/home/mfo/vndijk/.neditutil/test.f:9:122:beg:0x120001900
##### 1: MAIN__::i = 2




Now I want to add a second watch, for variable x:





##### (gdb) display MAIN__::x
##### A parse error in expression, near ':x'.




This is refused by gdb. Does gdb not want to discuss watches anymore? I
tried to inactivate the first watch:




##### (gdb) undisplay 1



No problem, watches are still negotiable for gdb. Can I re-activate the
watch that we just inactivated and which had worked the first time without
problems?




##### (gdb) display MAIN__::i
##### A parse error in expression, near ':i'.


No!
Now I just let the executable run to its end, to see if it mattered that it
was running. The first time when we successfully managed to set a watch for
variable "i", was before we gave the "run" command.




##### (gdb) clear test.f:9
##### Deleted breakpoint 1
##### (gdb) continue
##### Continuing.
##### Joehoe!
#####
##### Program exited normally.



Ok. Nothing is running now. Let's see if we can re-install the once
successful watch for "i":



##### (gdb) display MAIN__::i
##### A parse error in expression, near ':i'.


No!
What if we just reload the executable, even though there is already an
executable?



##### (gdb) file test.exe
##### Load new symbol table from "test.exe"? (y or n) y
##### Reading symbols from test.exe...done.
##### (gdb) display MAIN__::i
##### (gdb) display MAIN__::x
##### (gdb) break test.f:9
##### Breakpoint 2 at 0x120001900: file test.f, line 9.
##### (gdb) run
##### Starting program: /home/mfo/vndijk/.neditutil/test.exe
##### Have fun! 5
#####
##### Breakpoint 1, MAIN__ () at test.f:9
#####/home/mfo/vndijk/.neditutil/test.f:9:122:beg:0x120001900
##### 3: MAIN__::x = 1
##### 2: MAIN__::i = 1
##### Current language: auto; currently fortran
##### (gdb)




Now gdb all of a sudden has no problems with both i and x as watches!! This
was on the Dec Alpha. My Linux box still refuses the last watch, even after
a reload of the executable.

--> QUESTION: can someone help me here? I just want to follow watches and
be allowed to set them when they become of interest. This may well be while
the program is already running.

Thanks,

Arjan





Arjan van Dijk
Institute for Marine and Atmospheric Research Utrecht
Faculty of Physics and Astronomy
Utrecht University
Princetonplein 5
NL - 3584 CC  Utrecht
The Netherlands

phone: +31 30 2532815
fax:   +31 30 2543163
e-mail: mailto:A.vanDijk@phys.uu.nl
homepage: http://www.phys.uu.nl/~vndijk

Re: problem setting displays

[Daniel Jacobowitz]

On Fri, Sep 06, 2002 at 01:06:00PM +0200, Arjan van Dijk wrote:
> Now I want to add a second watch, for variable x:
> 
> 
> 
> 
> 
> ##### (gdb) display MAIN__::x
> ##### A parse error in expression, near ':x'.

That's not how you do it.  You run until you are in MAIN__ and "display
x".  Does that work?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: problem setting displays

[Arjan van Dijk]

>That's not how you do it.  You run until you are in MAIN__ and "display
>x".  Does that work?






No. The session that I showed only halted in MAIN__, so your condition was
satisfied and none of the displays that I tried to set were accepted.
Moreover, when I asked gdb to

   display MAIN__::i
   display MAIN__::x

before I said

   run

then all went ok. I had my watches every time gdb halted. As you may have
seen, no new watches were accepted once I commanded gdb to run. On 5.2.1 I
could get the watches after I reloaded the executable. On the Linux box
with gdb 5.0.x this did not work.

How can I have the value of a variable printed just once when program
execution halts? This instead of using "display". Maybe I could use such a
command. Would mean that I have to call all variables that I want to watch
every time the program halts, but until so far the 'display' command does
not seem to work.

Arjan


Arjan van Dijk
Institute for Marine and Atmospheric Research Utrecht
Faculty of Physics and Astronomy
Utrecht University
Princetonplein 5
NL - 3584 CC  Utrecht
The Netherlands

phone: +31 30 2532815
fax:   +31 30 2543163
e-mail: mailto:A.vanDijk@phys.uu.nl
homepage: http://www.phys.uu.nl/~vndijk

Re: problem setting displays

[Andrew Cagney]

> Hi,
> 
> In an attempt to circumvent the problems which I reported with the
> "display" command in gdb, I tried the "print" command, to get the value of
> a variable just once. This did not help. The same errors were reported by
> gdb as when I used the "display" command. Who can help?

That (in a sense) is good news.  It eliminates display from the problem.

I suspect it is a problem in either the fortran (that was fortran right 
:-) parser or the code that handes fortran variable scopes.   The other 
possability is that GDB loaded in additional debug information (gdb does 
this when it first hits a breakpoint for an object file) and that made 
the expression invalid.

sorry, just guesses.
Andrew

Re: problem setting displays

[Arjan van Dijk]

>That (in a sense) is good news.  It eliminates display from the problem.
>
>I suspect it is a problem in either the fortran (that was fortran right
>:-) parser or the code that handes fortran variable scopes.   The other
>possability is that GDB loaded in additional debug information (gdb does
>this when it first hits a breakpoint for an object file) and that made
>the expression invalid.


Hi,

Indeed it was fortran. Just plain g77, applied to a very simple example
program,  already makes the trouble. This makes me wonder why on earth the
two products, gdb and g77, both have a reference to GNU in their name, but
cannot collaborate. I find this very annoying. In a reaction to my second
attempt to get a reaction on this problem, Petr Sorfa <petrs@caldera.com>
gave me a reference to his project,
http://sourceforge.net/project/showfiles.php?group_id=56720
where he develops a gdb version which can handle Fortran (as long as the
compiler gives the right kind of debug info). In his gdb version (RC1), the
"print" command does not want to make a reference to a specific subroutine,
e.g. the command:

print subroutinename::variablename

does not (yet) work. Only "print variablename" works. This makes it
difficult to follow two variables both named "i" that are both involved in
a calculation, but which belong to different subroutines in the same
source-file (e.g. one calling the other). Also unfortunate is that this gdb
version does not compile on our Dec Alpha, but Petr already gave a
suggestion on how to try to solve this problem. On Linux it is a relief to
see this version simply eat the Fortran. I would be glad to see this
project be embraced by the maintainers of the official gdb distribution. So
far debugging Fortran is virtually impossible. I also wonder how the
Fortran community debugs its code. I fear that they all fall back on huge
amounts of write-statements and that they still live in the stone ages. Are
debuggers tools for quiche-eaters?

Regards,

Arjan


Arjan van Dijk
Institute for Marine and Atmospheric Research Utrecht
Faculty of Physics and Astronomy
Utrecht University
Princetonplein 5
NL - 3584 CC  Utrecht
The Netherlands

phone: +31 30 2532815
fax:   +31 30 2543163
e-mail: mailto:A.vanDijk@phys.uu.nl
homepage: http://www.phys.uu.nl/~vndijk