comp.lang.ada
 help / color / mirror / Atom feed
* Ada Community and GDB/Python problems
@ 2020-02-06 19:49 Rick Newbie
  2020-02-07 22:39 ` joakimds
  0 siblings, 1 reply; 5+ messages in thread
From: Rick Newbie @ 2020-02-06 19:49 UTC (permalink / raw)


Hi all,

I'm trying to get going with Ada community edition. So far so good but I 
had major problems with Python. I always get error messages when trying 
to debug, messages that show that the wrong number of parameters are 
provided to Python calls. It is as if the community pack contains the 
wrong version of Python.
For instance I compiled my hello world program with debug info etc, then 
tried to start gdb from the commandline. At first it tells me it can't 
find the pyton libraries. Then I follow the suggestions and supply the 
python path like so:

gdb --data-directory=D:\GNAT\2019\share\gdb-8.3

and I get a ton of errors:


Traceback (most recent call last):
   File "D:\GNAT\2019\share\gdb-8.3/python\gdb\__init__.py", line 143, 
in auto_load_packages
     __import__(modname)
   File "D:\GNAT\2019\share\gdb-8.3/python\gdb\command\explore.py", line 
746, in <module>
     Explorer.init_env()
   File "D:\GNAT\2019\share\gdb-8.3/python\gdb\command\explore.py", line 
135, in init_env
     gdb.TYPE_CODE_RVALUE_REF : ReferenceExplorer,
AttributeError: 'module' object has no attribute 'TYPE_CODE_RVALUE_REF'

Traceback (most recent call last):
   File "D:\GNAT\2019\share\gdb-8.3/python\gdb\__init__.py", line 143, 
in auto_load_packages
     __import__(modname)
   File 
"D:\GNAT\2019\share\gdb-8.3/python\gdb\command\frame_filters.py", line 
21, in <module>
     import copy
   File "D:\GNAT\2019\share\gdb-8.3\python-2.7.16\lib\copy.py", line 52, 
in <module>
     import weakref
   File "D:\GNAT\2019\share\gdb-8.3\python-2.7.16\lib\weakref.py", line 21
     ReferenceType),
                   ^
SyntaxError: invalid syntax

Traceback (most recent call last):
   File "D:\GNAT\2019\share\gdb-8.3/python\gdb\__init__.py", line 143, 
in auto_load_packages
     __import__(modname)
   File 
"D:\GNAT\2019\share\gdb-8.3/python\gdb\command\pretty_printers.py", line 
19, in <module>
     import copy
   File "D:\GNAT\2019\share\gdb-8.3\python-2.7.16\lib\copy.py", line 52, 
in <module>
     import weakref
   File "D:\GNAT\2019\share\gdb-8.3\python-2.7.16\lib\weakref.py", line 21
     ReferenceType),
                   ^
SyntaxError: invalid syntax

Traceback (most recent call last):
   File "D:\GNAT\2019\share\gdb-8.3/python\gdb\__init__.py", line 143, 
in auto_load_packages
     __import__(modname)
   File 
"D:\GNAT\2019\share\gdb-8.3/python\gdb\command\type_printers.py", line 
17, in <module>
     import copy
   File "D:\GNAT\2019\share\gdb-8.3\python-2.7.16\lib\copy.py", line 52, 
in <module>
     import weakref
   File "D:\GNAT\2019\share\gdb-8.3\python-2.7.16\lib\weakref.py", line 21
     ReferenceType),
                   ^
SyntaxError: invalid syntax

GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
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-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)



Again this is just the install package from Adacore. I am using Windows 
10 and I must admit that I don't have experience with gcc or gdb. To my 
knowledge there was never another python installation on my machine, not 
unless some other application installed it silently but I checked and 
can't find anything Python related, so this should be the only one 
(2.7.16). I just have no idea how to fix this since I would assume that 
the pack from Adacore should run out of the box.

Any help is appreciated.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Ada Community and GDB/Python problems
  2020-02-06 19:49 Ada Community and GDB/Python problems Rick Newbie
@ 2020-02-07 22:39 ` joakimds
  2020-02-08  6:19   ` J-P. Rosen
  2020-02-08 10:27   ` Dmitry A. Kazakov
  0 siblings, 2 replies; 5+ messages in thread
From: joakimds @ 2020-02-07 22:39 UTC (permalink / raw)


Hi Rick,

I would recommend tracing to "debug" what your application is doing (either print messages to standard out or logging to a file). In a multi-task application I've preferred tracing for a long time over stepping through code using a debugger like gdb. When using the GNAT Pro version of GNAT I've never had any issue with gdb and it has worked very well to step through code using it. However, rarely I've managed to get it working with the community edition and in my mind I've just thought about it like "if I want to use the debugger dbg I should use GNAT Pro". Maybe others in the Ada community has had a more positive experience with gdb using GNAT CE?

Best regards,
Joakim

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Ada Community and GDB/Python problems
  2020-02-07 22:39 ` joakimds
@ 2020-02-08  6:19   ` J-P. Rosen
  2020-02-09 17:28     ` Rick Newbie
  2020-02-08 10:27   ` Dmitry A. Kazakov
  1 sibling, 1 reply; 5+ messages in thread
From: J-P. Rosen @ 2020-02-08  6:19 UTC (permalink / raw)


Le 07/02/2020 à 23:39, joakimds@kth.se a écrit :
> I would recommend tracing to "debug" what your application is doing
> (either print messages to standard out or logging to a file). In a
> multi-task application I've preferred tracing for a long time over
> stepping through code using a debugger like gdb.

I agree, I use tracing every day, and gdb no more than 2-3 times a year.
Not that there is any problem with gdb, but (at least for my kind of
debugging), I find tracing more efficient.

<plug>Especially if you are using multiple tasks, I recommend the
"Debug" package that you can get (free) from
http://adalog.fr/en/components.html#Debug

Among other things, it shows task switches and allows you to trace
protected calls (reminder: you are not allowed to print from within a
protected operation).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Ada Community and GDB/Python problems
  2020-02-07 22:39 ` joakimds
  2020-02-08  6:19   ` J-P. Rosen
@ 2020-02-08 10:27   ` Dmitry A. Kazakov
  1 sibling, 0 replies; 5+ messages in thread
From: Dmitry A. Kazakov @ 2020-02-08 10:27 UTC (permalink / raw)


On 2020-02-07 23:39, joakimds@kth.se wrote:

> I would recommend tracing to "debug" what your application is doing (either print messages to standard out or logging to a file). In a multi-task application I've preferred tracing for a long time over stepping through code using a debugger like gdb.

I agree about tracing, but tracing too could be provided by the 
debugger, without necessity to alter the source code.

Assuming the debugger is not the miserable mess GDB is.

> When using the GNAT Pro version of GNAT I've never had any issue with gdb and it has worked very well to step through code using it. However, rarely I've managed to get it working with the community edition and in my mind I've just thought about it like "if I want to use the debugger dbg I should use GNAT Pro". Maybe others in the Ada community has had a more positive experience with gdb using GNAT CE?

I never managed GDB working even in GNAT PRO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Ada Community and GDB/Python problems
  2020-02-08  6:19   ` J-P. Rosen
@ 2020-02-09 17:28     ` Rick Newbie
  0 siblings, 0 replies; 5+ messages in thread
From: Rick Newbie @ 2020-02-09 17:28 UTC (permalink / raw)


On 2/7/2020 10:19 PM, J-P. Rosen wrote:
> Le 07/02/2020 à 23:39, joakimds@kth.se a écrit :
>> I would recommend tracing to "debug" what your application is doing
>> (either print messages to standard out or logging to a file). In a
>> multi-task application I've preferred tracing for a long time over
>> stepping through code using a debugger like gdb.
> 
> I agree, I use tracing every day, and gdb no more than 2-3 times a year.
> Not that there is any problem with gdb, but (at least for my kind of
> debugging), I find tracing more efficient.
> 
> <plug>Especially if you are using multiple tasks, I recommend the
> "Debug" package that you can get (free) from
> http://adalog.fr/en/components.html#Debug
> 
> Among other things, it shows task switches and allows you to trace
> protected calls (reminder: you are not allowed to print from within a
> protected operation).
> 
On 2/7/2020 10:19 PM, J-P. Rosen wrote:
 > Le 07/02/2020 à 23:39, joakimds@kth.se a écrit :
 >> I would recommend tracing to "debug" what your application is doing
 >> (either print messages to standard out or logging to a file). In a
 >> multi-task application I've preferred tracing for a long time over
 >> stepping through code using a debugger like gdb.
Thanks, also thnks for the link to the Ada tools. Actually I use tracing 
in my current C++ program and it is helpful, but I still prefer to step 
through new code at least once to see that the logic works as intended 
and the variables are computed correctly.

As for my original problems, I have finally figured out what the problem 
is and will post a solution further down. I must say I find it 
astounding though that Adacore releases a package like the community 
edition that contains these obvious bugs. A simple install on a clean 
Windows machine should have revealed the problem. My guess is they have 
multiple Python installations and never loaded the script from the 
location that is shipped with the Community pack.





-------
The following environment variables must be set


PYTHONHOME = D:\GNAT\2019\share\gdb-8.3\python-2.7.16
PYTHONPATH=D:\GNAT\2019\share\gdb-8.3\python-2.7.16\lib

In PATH make sure D:\GNAT\2019\bin is set before the path to slickedit 
if you have slickedit. Slickedit comes with python it might interfere 
with the GPS version of Python.

In D:\GNAT\2019\share\gdb-8.3\python-2.7.16\Lib\weakref.py there is an 
error:

from _weakref import (
      getweakrefcount,
      getweakrefs,
      ref,
      proxy,
      CallableProxyType,
      ProxyType,
      ReferenceType),
       _remove_dead_weakref)

Change to:
from _weakref import (
      getweakrefcount,
      getweakrefs,
      ref,
      proxy,
      CallableProxyType,
      ProxyType,
      ReferenceType)
#from _weakref import _remove_dead_weakref

the _remove_dead_weakrefimport will not be found, so we must comment it 
out. GDB will now run, but complain that it can't find a path to an 
index directory which may or may not be related but seems to cause no 
more errors




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-02-09 17:28 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-06 19:49 Ada Community and GDB/Python problems Rick Newbie
2020-02-07 22:39 ` joakimds
2020-02-08  6:19   ` J-P. Rosen
2020-02-09 17:28     ` Rick Newbie
2020-02-08 10:27   ` Dmitry A. Kazakov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox