* Re: Alternative for Gnat Studio
2021-02-25 12:43 ` ldries46
@ 2021-02-25 14:48 ` Dennis Lee Bieber
2021-02-25 18:10 ` Simon Wright
` (2 subsequent siblings)
3 siblings, 0 replies; 41+ messages in thread
From: Dennis Lee Bieber @ 2021-02-25 14:48 UTC (permalink / raw)
On Thu, 25 Feb 2021 13:43:20 +0100, ldries46 <bertus.dries@planet.nl>
declaimed the following:
>My problem has become more acute. Till now I avoided the debugging
>option in the GNAT 2020 Community edition by badding print statements
>within the normal running program but now I have an error mentioned
>somewhere within the Ada. Unbounded_Strings which is used on a lot of
>positions in the program. The only way I know to detect wher the problem
>is is using the debug option with several brakpoints and as possible
>shifting these around to find this error but uding the debu option just
>makes the program coming to the "program does not react". So either this
>problem must be solved (who knows how) or an other compiler and debugger
>combination that really works (and is freeware) Who knows which and has
>a good tutorial how to install. Up to this moment with Visual Suodio I
>do not know how to do that.
So far as I know, the debugger used for GNAT is a version of GDB.
GDB originated with a command line interface. Have you tried opening a
command shell and invoking the debugger (and your executable) from there,
then using GDB commands to set any needed breakpoints, etc.?
I've never used GDB so my knowledge is rather limited -- I'd have to
keep the help file open in a browser. The last debugger I had any real
experience using was the one in (Open)VMS, and I was usually debugging F77
logic. I've also not updated to GNAT 2020 yet -- looks like 2019 has some
Python related glitches too, but it did run...
-=-=-
C:\Users\Wulfraed\Documents\_Hg-Repositories\Ada Progs>gdb threeint.exe
C:\GNAT\2019\bin\gdb.exe: warning: Couldn't determine a path for the index
cache directory.
Traceback (most recent call last):
File "c:\gnat\2019\share\gdb-8.3/python\gdb\__init__.py", line 143, in
auto_load_packages
__import__(modname)
File "c:\gnat\2019\share\gdb-8.3/python\gdb\command\frame_filters.py",
line 21, in <module>
import copy
File "c:\gnat\2019\share\gdb-8.3\python-2.7.16\lib\copy.py", line 52, in
<module>
import weakref
File "c:\gnat\2019\share\gdb-8.3\python-2.7.16\lib\weakref.py", line 14,
in <module>
from _weakref import (
ImportError: cannot import name _remove_dead_weakref
Traceback (most recent call last):
File "c:\gnat\2019\share\gdb-8.3/python\gdb\__init__.py", line 143, in
auto_load_packages
__import__(modname)
File "c:\gnat\2019\share\gdb-8.3/python\gdb\command\pretty_printers.py",
line 19, in <module>
import copy
File "c:\gnat\2019\share\gdb-8.3\python-2.7.16\lib\copy.py", line 52, in
<module>
import weakref
File "c:\gnat\2019\share\gdb-8.3\python-2.7.16\lib\weakref.py", line 14,
in <module>
from _weakref import (
ImportError: cannot import name _remove_dead_weakref
Traceback (most recent call last):
File "c:\gnat\2019\share\gdb-8.3/python\gdb\__init__.py", line 143, in
auto_load_packages
__import__(modname)
File "c:\gnat\2019\share\gdb-8.3/python\gdb\command\type_printers.py",
line 17, in <module>
import copy
File "c:\gnat\2019\share\gdb-8.3\python-2.7.16\lib\copy.py", line 52, in
<module>
import weakref
File "c:\gnat\2019\share\gdb-8.3\python-2.7.16\lib\weakref.py", line 14,
in <module>
from _weakref import (
ImportError: cannot import name _remove_dead_weakref
GNU gdb (GDB) 8.3 for GNAT Community 2019 [rev=gdb-8.3-ref-194-g3fc1095]
Copyright (C) 2019 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.
See your support agreement for details of warranty and support.
If you do not have a current support agreement, then there is absolutely
no warranty for this version of GDB.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-mingw32".
Type "show configuration" for configuration details.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from threeint.exe...
(gdb) r
Starting program: C:\Users\Wulfraed\Documents\_Hg-Repositories\Ada
Progs\threeint.exe
[New Thread 15068.0x17a0]
[New Thread 15068.0x5f0]
Enter three integers => 123
456
8373
A + B = 579
C - B = 7917
[Thread 15068.0x17a0 exited with code 0]
[Thread 15068.0x5f0 exited with code 0]
[Inferior 1 (process 15068) exited normally]
(gdb) q
C:\Users\Wulfraed\Documents\_Hg-Repositories\Ada Progs>
-=-=-
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Alternative for Gnat Studio
2021-02-25 12:43 ` ldries46
2021-02-25 14:48 ` Dennis Lee Bieber
@ 2021-02-25 18:10 ` Simon Wright
2021-02-25 23:51 ` Stephen Leake
2021-02-26 7:56 ` Dmitry A. Kazakov
3 siblings, 0 replies; 41+ messages in thread
From: Simon Wright @ 2021-02-25 18:10 UTC (permalink / raw)
ldries46 <bertus.dries@planet.nl> writes:
> My problem has become more acute. Till now I avoided the debugging
> option in the GNAT 2020 Community edition by badding print statements
> within the normal running program but now I have an error mentioned
> somewhere within the Ada. Unbounded_Strings which is used on a lot of
> positions in the program. The only way I know to detect wher the
> problem is is using the debug option with several brakpoints and as
> possible shifting these around to find this error but uding the debu
> option just makes the program coming to the "program does not
> react".
If you can possibly bear it, you should try the command line. I don't
know what that would look like on Windows (unless you're using Cygwin?
which is Unix-y).
Sample program:
pragma Assertion_Policy (Check);
procedure Raiser is
procedure Inner (N : Natural) is
pragma Assert (N > 5);
begin
Inner (N - 1);
end Inner;
begin
Inner (10);
end Raiser;
Now, I'm sure you've built with a proper GPR, but to simplify the
example:
gnatmake -g -O raiser.adb
Here, this produces the executable "raiser" in the current directory,
but if your GPR specifies the Object_Dir and not the Exec_Dir the
executable (in your case "raiser.exe") ends up in the Object_Dir, drat
it.
A very simple debugging session, assuming that the command "gdb" runs OK
might look like:
$ gdb raiser
GNU gdb (GDB) 7.10 for GNAT Community 2020 [rev=52ea9f0a422c99f69e7e6c44a04e654ceebc42e3]
Copyright (C) 2015 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.
See your support agreement for details of warranty and support.
If you do not have a current support agreement, then there is absolutely
no warranty for this version of GDB. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin17.7.0".
Type "show configuration" for configuration details.For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from raiser...done.
Stop on any exception
(gdb) catch exception
Catchpoint 1: all Ada exceptions
Run to the start of the program
(gdb) start
Temporary breakpoint 2 at 0x100001f54: file raiser.adb, line 9.
Starting program: /Users/simon/tmp/raiser
[New Thread 0x2303 of process 71543]
Temporary breakpoint 2, raiser () at raiser.adb:9
9 Inner (10);
Carry on
(gdb) continue
Continuing.
Oops! (note, gdb knows to stop at the point in my code where the
exception was raised, rather than down in the details of the runtime
system calls)
Catchpoint 1, SYSTEM.ASSERTIONS.ASSERT_FAILURE (raiser.adb:4) at 0x0000000100001f17 in raiser.inner (n=5) at raiser.adb:4
4 pragma Assert (N > 5);
Print a backtrace of how we got here
(gdb) backtrace
#0 <__gnat_debug_raise_exception> (
e=0x1000142e0 <system.assertions.assert_failure>, message=...)
at s-excdeb.adb:43
#1 0x00000001000038ed in ada.exceptions.complete_occurrence (x=0x1004040c0)
at a-except.adb:931
#2 0x00000001000038fd in ada.exceptions.complete_and_propagate_occurrence (
x=0x1004040c0) at a-except.adb:942
#3 0x0000000100003952 in <__gnat_raise_exception> (
e=0x1000142e0 <system.assertions.assert_failure>, message=...)
at a-except.adb:984
#4 0x0000000100004c13 in system.assertions.raise_assert_failure (msg=...)
at s-assert.adb:46
#5 0x0000000100001f17 in raiser.inner (n=5) at raiser.adb:4
#6 0x0000000100001f3c in raiser.inner (n=6) at raiser.adb:6
#7 0x0000000100001f3c in raiser.inner (n=7) at raiser.adb:6
#8 0x0000000100001f3c in raiser.inner (n=8) at raiser.adb:6
#9 0x0000000100001f3c in raiser.inner (n=9) at raiser.adb:6
#10 0x0000000100001f3c in raiser.inner (n=10) at raiser.adb:6
#11 0x0000000100001f65 in raiser () at raiser.adb:9
Look at the code at frame 8 (#8 in the backtrace)
(gdb) frame 8
#8 0x0000000100001f3c in raiser.inner (n=8) at raiser.adb:6
6 Inner (N - 1);
Print a variable
(gdb) print n
$1 = 8
(gdb)
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Alternative for Gnat Studio
2021-02-25 12:43 ` ldries46
2021-02-25 14:48 ` Dennis Lee Bieber
2021-02-25 18:10 ` Simon Wright
@ 2021-02-25 23:51 ` Stephen Leake
2021-02-26 7:56 ` Dmitry A. Kazakov
3 siblings, 0 replies; 41+ messages in thread
From: Stephen Leake @ 2021-02-25 23:51 UTC (permalink / raw)
ldries46 <bertus.dries@planet.nl> writes:
> Op 18-2-2021 om 13:41 schreef ldries46:
>> At this moment I am using GNAT Studio for Ada programming.
>> Now I have two reasons for a possible change:
>>
>> 1. I read somewhere that the freeware version is not going to be
>> continued. Is that true?
>> 2. I have proroblems with the program (I cannot use it any more
>> becasuse it is reacts with the program I am busy with "Program
>> does not react".
>>
>> Because Gnatstudio has simple one command Instalation procedure it
>> is easy for me to understand for me hoe to install it. Is there an
>> alternative that is almost as easy to install which I can use,
>> preferably with an simple and good readable description how to
>> install it.
>>
>>
>> L. Dries
>>
> My problem has become more acute.
I suggest you try Emacs ada-mode (it's an ELPA package).
Installing is a little messy; you have to install some gnatcoll
components and run a shell program. Which means you have to install
mingw64; strongly recommended anyway.
You can report problems here or on the Emacs ada-mode mailing list
(https://savannah.nongnu.org/projects/ada-mode/)
--
-- Stephe
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Alternative for Gnat Studio
2021-02-25 12:43 ` ldries46
` (2 preceding siblings ...)
2021-02-25 23:51 ` Stephen Leake
@ 2021-02-26 7:56 ` Dmitry A. Kazakov
2021-02-28 22:54 ` Stephen Leake
3 siblings, 1 reply; 41+ messages in thread
From: Dmitry A. Kazakov @ 2021-02-26 7:56 UTC (permalink / raw)
On 2021-02-25 13:43, ldries46 wrote:
> Op 18-2-2021 om 13:41 schreef ldries46:
>> At this moment I am using GNAT Studio for Ada programming.
>> Now I have two reasons for a possible change:
>>
>> 1. I read somewhere that the freeware version is not going to be
>> continued. Is that true?
>> 2. I have proroblems with the program (I cannot use it any more
>> becasuse it is reacts with the program I am busy with "Program
>> does not react".
>>
>> Because Gnatstudio has simple one command Instalation procedure it is
>> easy for me to understand for me hoe to install it. Is there an
>> alternative that is almost as easy to install which I can use,
>> preferably with an simple and good readable description how to install
>> it.
>>
>>
>> L. Dries
>>
> My problem has become more acute. Till now I avoided the debugging
> option in the GNAT 2020 Community edition by badding print statements
> within the normal running program but now I have an error mentioned
> somewhere within the Ada. Unbounded_Strings which is used on a lot of
> positions in the program. The only way I know to detect wher the problem
> is is using the debug option with several brakpoints and as possible
> shifting these around to find this error but uding the debu option just
> makes the program coming to the "program does not react".
GDB and IDE are different things. GDB never really worked for complex
projects and, I am afraid, it never will.
Then resolving a complex issue like you describe with debugger is
unrealistic anyway. If you have a memory corruption, e.g. per concurrent
access, debugger is not much help, even a good debugger, rather than the
garbage GDB is.
The first step is to set an exception handler and trace all exceptions
before they propagate. See GNAT.Exception_Action.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Alternative for Gnat Studio
2021-02-26 7:56 ` Dmitry A. Kazakov
@ 2021-02-28 22:54 ` Stephen Leake
2021-03-01 18:04 ` Ludovic Brenta
2021-03-02 5:11 ` John Perry
0 siblings, 2 replies; 41+ messages in thread
From: Stephen Leake @ 2021-02-28 22:54 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> GDB and IDE are different things. GDB never really worked for complex
> projects and, I am afraid, it never will.
GDB has always met my needs, programming spacecraft simulators for NASA.
--
-- Stephe
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Alternative for Gnat Studio
2021-02-28 22:54 ` Stephen Leake
@ 2021-03-01 18:04 ` Ludovic Brenta
2021-03-02 5:11 ` John Perry
1 sibling, 0 replies; 41+ messages in thread
From: Ludovic Brenta @ 2021-03-01 18:04 UTC (permalink / raw)
Stephen Leake <stephen_leake@stephe-leake.org> writes:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> GDB and IDE are different things. GDB never really worked for complex
>> projects and, I am afraid, it never will.
>
> GDB has always met my needs, programming spacecraft simulators for
> NASA.
In addition:
For memory corruption, the memcheck tool of valgrind is extremely
valuable. This is a rare occurrence in Ada but use-after-free can still
happen.
For race conditions, the helgrind tool of valgrind is extremely
valuable. Again, a rare occurrence in Ada if you use protected objects
but not so rare if you use rendez-vous between tasks.
Of course, we're only talking about "complex" projects here. That is,
technology sufficiently "advanced" to seem "magical" :)
--
Ludovic Brenta.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Alternative for Gnat Studio
2021-02-28 22:54 ` Stephen Leake
2021-03-01 18:04 ` Ludovic Brenta
@ 2021-03-02 5:11 ` John Perry
2021-03-02 8:04 ` Simon Wright
` (2 more replies)
1 sibling, 3 replies; 41+ messages in thread
From: John Perry @ 2021-03-02 5:11 UTC (permalink / raw)
On Sunday, February 28, 2021 at 4:54:30 PM UTC-6, Stephen Leake wrote:
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
>
> > GDB and IDE are different things. GDB never really worked for complex
> > projects and, I am afraid, it never will.
> GDB has always met my needs, programming spacecraft simulators for NASA.
>
Honest question: do you have advice for debugging exceptions in GDB?*** I had to debug an exception the other day & I had a humdinger of a time determining what caused it. When the Ada RT raises an exception in GDB, GDB quits the program state altogether, so I have to employ guess-and-check methods to figure out where, say, an Ordered_Map Key_Error occurs. This is contrary to how GDB handles C++ exceptions: the program stops immediately, so that you can examine the state, move up and down through the stack, etc.
I've used GDB a lot with C++, so I don't find it as bad as Dmitry says, but it's a much poorer experience when debugging Ada. (Still useful!)
***Aside from writing programs that don't raise them, of course. ;-)
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Alternative for Gnat Studio
2021-03-02 5:11 ` John Perry
@ 2021-03-02 8:04 ` Simon Wright
2021-03-02 8:08 ` Emmanuel Briot
2021-03-05 12:58 ` ldries46
2 siblings, 0 replies; 41+ messages in thread
From: Simon Wright @ 2021-03-02 8:04 UTC (permalink / raw)
John Perry <john.perry@usm.edu> writes:
> Honest question: do you have advice for debugging exceptions in
> GDB?*** I had to debug an exception the other day & I had a humdinger
> of a time determining what caused it. When the Ada RT raises an
> exception in GDB, GDB quits the program state altogether, so I have to
> employ guess-and-check methods to figure out where, say, an
> Ordered_Map Key_Error occurs. This is contrary to how GDB handles C++
> exceptions: the program stops immediately, so that you can examine the
> state, move up and down through the stack, etc.
I don't remember experiencing this? "catch exception" or "catch
exception Key_Error". I may not be able to see much in the RTS, but
I can certainly inspect my own code.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Alternative for Gnat Studio
2021-03-02 5:11 ` John Perry
2021-03-02 8:04 ` Simon Wright
@ 2021-03-02 8:08 ` Emmanuel Briot
2021-03-02 9:13 ` rr (was: Re: Alternative for Gnat Studio) Simon Wright
2021-03-03 3:31 ` Alternative for Gnat Studio John Perry
2021-03-05 12:58 ` ldries46
2 siblings, 2 replies; 41+ messages in thread
From: Emmanuel Briot @ 2021-03-02 8:08 UTC (permalink / raw)
> Honest question: do you have advice for debugging exceptions in GDB?***
Do you know about the "catch exception" command ? gdb will automatically break when an exception is raised. There could be a lot of these, so you can also try the variant "catch exception unhandled".
This doesn't always help to investigate what happened just before an exception, so we have also started using the "rr" tool, which basically executes your program and records everything at every step, so that you can replay it. There is a cost in performance of course, but not as big as one would expect.
Finally, going back to the subject of this thread (alternative IDEs), I just found the following video on AdaCore's website. It describes the new cross-referencing engine in GNAT Studio, and how it can be used with other IDEs, in particular Visual Studio Code.
https://www.adacore.com/product-update-2020/gnatstudio-update
Emmanuel
^ permalink raw reply [flat|nested] 41+ messages in thread
* rr (was: Re: Alternative for Gnat Studio)
2021-03-02 8:08 ` Emmanuel Briot
@ 2021-03-02 9:13 ` Simon Wright
2021-03-02 9:23 ` Emmanuel Briot
2021-03-04 22:53 ` rr Simon Wright
2021-03-03 3:31 ` Alternative for Gnat Studio John Perry
1 sibling, 2 replies; 41+ messages in thread
From: Simon Wright @ 2021-03-02 9:13 UTC (permalink / raw)
Emmanuel Briot <briot.emmanuel@gmail.com> writes:
> Do you know about the "catch exception" command ? gdb will
> automatically break when an exception is raised. There could be a lot
> of these, so you can also try the variant "catch exception unhandled".
> This doesn't always help to investigate what happened just before an
> exception, so we have also started using the "rr" tool, which
> basically executes your program and records everything at every step,
> so that you can replay it. There is a cost in performance of course,
> but not as big as one would expect.
It's a shame (but not surprising!) that this is Linux-only.
It'd probably really help with my current problem, where GCC 11.0.0 and
GNAT CE 2020 arm-eabi throw an ICE when compiling a generalised
iteration with my Cortex GNAT RTS (no problem compiling against an
AdaCore RTS). Building the compiler with debugging, OK-ish (CFLAGS='-g
-O0'). Finding the exact invocation of gcc, OK (gprbuild -v
--keep-temp-files). Calling that invocation and getting GDB to start
with the actual gnat1 call, OK (add -wrapper gdb,--args to the gcc
command). Setting a break on the place where the ICE is raised, OK (b
sem_ch8.adb:5490). But then you've got a lengthy traceback, at some
point in which the compiler was misled by something in my runtime to
construct something wrongly.
There are definitely runtime-related aspects to the analysis: f.e. in
Exp_Ch6.Add_Task_Actuals_To_Build_In_Place_Call, there's a line (:596
here)
-- Use a dummy _master actual in case of No_Task_Hierarchy
if Restriction_Active (No_Task_Hierarchy) then
Actual := New_Occurrence_Of (RTE (RE_Library_Task_Level), Loc);
Someone familiar with the compiler internals, and how to explore them in
the debugger, would no doubt find what's wrong in a flash, but I doubt
that posting on the GCC Bugzilla would get a speedy response!
https://github.com/rr-debugger/rr
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: rr (was: Re: Alternative for Gnat Studio)
2021-03-02 9:13 ` rr (was: Re: Alternative for Gnat Studio) Simon Wright
@ 2021-03-02 9:23 ` Emmanuel Briot
2021-03-04 22:48 ` rr Simon Wright
2021-03-04 22:53 ` rr Simon Wright
1 sibling, 1 reply; 41+ messages in thread
From: Emmanuel Briot @ 2021-03-02 9:23 UTC (permalink / raw)
> It'd probably really help with my current problem, where GCC 11.0.0 and
> GNAT CE 2020 arm-eabi throw an ICE when compiling a generalised
> iteration
Might be unrelated, but: we have noticed recently that a generalized iteration ("for..of")
was wrongly calling `activate_task`. In particular, this resulted in errors when executing such
loops from a protected object and enabling the checks that no potentially blocking operation
is executed in such contexts.
We reported this to AdaCore who fixed it in their more recent wavefronts. I am not sure when the
error started to occur though, so maybe not that helpful to you :-)
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: rr
2021-03-02 9:23 ` Emmanuel Briot
@ 2021-03-04 22:48 ` Simon Wright
0 siblings, 0 replies; 41+ messages in thread
From: Simon Wright @ 2021-03-04 22:48 UTC (permalink / raw)
Emmanuel Briot <briot.emmanuel@gmail.com> writes:
>> It'd probably really help with my current problem, where GCC 11.0.0 and
>> GNAT CE 2020 arm-eabi throw an ICE when compiling a generalised
>> iteration
>
> Might be unrelated, but: we have noticed recently that a generalized
> iteration ("for..of") was wrongly calling `activate_task`. In
> particular, this resulted in errors when executing such loops from a
> protected object and enabling the checks that no potentially blocking
> operation is executed in such contexts.
>
> We reported this to AdaCore who fixed it in their more recent
> wavefronts. I am not sure when the
> error started to occur though, so maybe not that helpful to you :-)
I reported this, and Eric has come up with the goods! We're at 11.0.1
now (how can you tell what release ID a particular GCC commit will
produce?), so there's a good chance it'll make it into the 11.1.0
release.
Not that there are likely to be loads of people around making RTSs with
Ada.Containers for MCUs. The issue didn't cause problems with AdaCore's
ravenscar-full-stm32f4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: rr
2021-03-02 9:13 ` rr (was: Re: Alternative for Gnat Studio) Simon Wright
2021-03-02 9:23 ` Emmanuel Briot
@ 2021-03-04 22:53 ` Simon Wright
2021-03-05 6:53 ` rr Emmanuel Briot
1 sibling, 1 reply; 41+ messages in thread
From: Simon Wright @ 2021-03-04 22:53 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> I doubt that posting on the GCC Bugzilla would get a speedy response
In this case, it did[1]. Nothing like being able to provide a reproducer
(and having ICE, Internal Compiler Error, in the description may help
too).
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: rr
2021-03-04 22:53 ` rr Simon Wright
@ 2021-03-05 6:53 ` Emmanuel Briot
0 siblings, 0 replies; 41+ messages in thread
From: Emmanuel Briot @ 2021-03-05 6:53 UTC (permalink / raw)
> > I doubt that posting on the GCC Bugzilla would get a speedy response
> In this case, it did[1]. Nothing like being able to provide a reproducer
> (and having ICE, Internal Compiler Error, in the description may help
> too).
Even as a supported customer, it does help a lot when we can provide a small self-contained reproducer. Such bugs (including with "ICE" in the subject, we use the same trick :-) tend to be fixed pretty fast.
This is time consuming for compilation errors, but on the whole it takes one to two hours in general.
For run time issues (we currently have an optimization bug for instance), this is way more complex...
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Alternative for Gnat Studio
2021-03-02 8:08 ` Emmanuel Briot
2021-03-02 9:13 ` rr (was: Re: Alternative for Gnat Studio) Simon Wright
@ 2021-03-03 3:31 ` John Perry
1 sibling, 0 replies; 41+ messages in thread
From: John Perry @ 2021-03-03 3:31 UTC (permalink / raw)
On Tuesday, March 2, 2021 at 2:08:25 AM UTC-6, briot.e...@gmail.com wrote:
> > Honest question: do you have advice for debugging exceptions in GDB?***
> Do you know about the "catch exception" command ? gdb will automatically break when an exception is raised. There could be a lot of these, so you can also try the variant "catch exception unhandled".
Nope, that's new to me. I'll try it next time, thanks.
john perry
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Alternative for Gnat Studio
2021-03-02 5:11 ` John Perry
2021-03-02 8:04 ` Simon Wright
2021-03-02 8:08 ` Emmanuel Briot
@ 2021-03-05 12:58 ` ldries46
2021-03-05 13:24 ` J-P. Rosen
2 siblings, 1 reply; 41+ messages in thread
From: ldries46 @ 2021-03-05 12:58 UTC (permalink / raw)
Op 2-3-2021 om 6:11 schreef John Perry:
> On Sunday, February 28, 2021 at 4:54:30 PM UTC-6, Stephen Leake wrote:
>> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
>>
>>> GDB and IDE are different things. GDB never really worked for complex
>>> projects and, I am afraid, it never will.
>> GDB has always met my needs, programming spacecraft simulators for NASA.
>>
> Honest question: do you have advice for debugging exceptions in GDB?*** I had to debug an exception the other day & I had a humdinger of a time determining what caused it. When the Ada RT raises an exception in GDB, GDB quits the program state altogether, so I have to employ guess-and-check methods to figure out where, say, an Ordered_Map Key_Error occurs. This is contrary to how GDB handles C++ exceptions: the program stops immediately, so that you can examine the state, move up and down through the stack, etc.
>
> I've used GDB a lot with C++, so I don't find it as bad as Dmitry says, but it's a much poorer experience when debugging Ada. (Still useful!)
>
> ***Aside from writing programs that don't raise them, of course. ;-)
I am normally using severaldifferent methods of debugging tohether:
1. using an extra package that is only used to create simple output to
the cmd window or the equivalent in the GPS studio program. This
creates output over the full run the program m makes. By deleting
the call to the package it is easy todelete all extra statements.
2. In the case of programs with a GUI using extra calls to that GUI
3. GDB in situations where it necessary to follow the program statement
by statement
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: Alternative for Gnat Studio
2021-03-05 12:58 ` ldries46
@ 2021-03-05 13:24 ` J-P. Rosen
0 siblings, 0 replies; 41+ messages in thread
From: J-P. Rosen @ 2021-03-05 13:24 UTC (permalink / raw)
Le 05/03/2021 à 13:58, ldries46 a écrit :
> I am normally using severaldifferent methods of debugging tohether:
>
> 1. using an extra package that is only used to create simple output to
> the cmd window or the equivalent in the GPS studio program. This
> creates output over the full run the program m makes. By deleting
> the call to the package it is easy todelete all extra statements.
To do this, I recommend ;-) package Debug from Adalog, see:
https://adalog.fr/en/components.html#Debug
--
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] 41+ messages in thread