Re: Intervention needed?

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

On Saturday, April 6, 2019 at 12:25:48 AM UTC-4, alby....@gmail.com wrote:
> On Saturday, April 6, 2019 at 12:38:57 PM UTC+11, Jere wrote:
> > 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.
> 
> Has anyone tried the debugging support in VisualAda. It supports both GDB via
> the MI interface and if you opt in to use the MS linker, you can also use the
> native MS debugger.
> 
> Both options support setting breakpoints, view/change symbols/variables, etc..
> 
> Note the native debugger will also present the internal symbols/variables, not
> sure if this is a good or a bad thing?. 
> 
> One of the enhancements that I plan for the next release is adding some debug
> visualizers for types such as strings and unbounded strings, which by default
> are not presented / shown in a user friendly manner
> 
> Suggestions on other improvements are welcome
> 
> Alex

I started to try it out seriously a while back, but it required a specific 
installation path of some things and I did not have that setup the way it
wanted.  I've been meaning to take a stab at it again.  I've just been 
distracted.