Re: Intervention needed?

[Jere <jhb.chat@gmail.com>]

On Friday, April 5, 2019 at 11:17:55 AM UTC-4, Optikos wrote:
> On Friday, April 5, 2019 at 1:45:20 AM UTC-4, Maciej Sobczak wrote:
> > > As gdb can be scripted, the tests that Maciej describes can probably be 
> > > automated,
> > 
> > Yes.
> > 
> > > albeit with considerable effort,
> > 
> > Not really. I would say there is no need for this effort to be higher than with any other form of test automation. Note that as with anything else in software, recurring problems can be mitigated by additional code. That is, if testing this way is difficult, then the difficulty is similar for the whole class of similar tests and as such that difficulty can be refactored away to additional utility (library/framework/etc.) with simpler (higher-level) interface.
> > 
> > > especially if the scripts 
> > > should be robust to evolution of the SW under test (changing the line 
> > > numbers of the required breakpoints, etc.)
> > 
> > This is a wider problem of traceability. You have to solve this problem anyway for the coverage analysis, for example. And the solution, whatever you happen to use (like tool-readable labels in source comments), will help with debugging, too.
> > 
> > In any case, yes, some projects need the debugger to test individual memory locations. The lack of proper tools is a technology risk.
> > 
> > > However, I don't think that gdb or other current debuggers are 
> > > ideal tools for automated checking of internal states.
> > 
> > They are not. But a non-ideal working debugger is still better than a not working one.
> 
> Which features do you consider as missing in GDB regarding GNAT Ada that make GDB non-ideal?

I can't speak for GDB specifically, but at some point (2015 maybe?) they
redid the GUI interface in GPS to the debugger and it became completely 
unintuitive for me.  The few times I have had to debug Ada code involved
access types and manual memory management.  They used to have a really
good interface that would visually display records and fields, and when
I clicked on an access type variable, it would pop open another box with
the record that variable pointed to.  For custom containers this was really
handy for debugging.  It was a very handy and visual way to map out memory
for those rarer times I had to actually manage it.  Now I just use my
Smart_Access packages (once they fixed the GNAT bugs), though I still 
don't expose those to clients.