[Info-vax] ada archives and debug

[johnwallace4 at yahoo.co.uk]

On Saturday, 20 January 2018 07:13:16 UTC, Tristan Gingold  wrote:
> Johnny Billquist <bqt at softjar.se> writes:
> 
> > On 2018-01-18 19:44, Simon Clubley wrote:
> >> On 2018-01-18, gérard Calliet <gerard.calliet at pia-sofer.fr> wrote:
> >>>
> >>> Now customers demand debug. I'm in the beginning of evalution of this
> >>> facility.
> >>>
> >>> For what I know, Adacore didn't give debug (in VMS style), and they say
> >>> HP didn't "cooperate" on that. I'm wondering if there are been effort
> >>> for that anywhere.
> >>>
> >>
> >> What's wrong with simply using gdb or are you saying that it wasn't
> >> possible for you to build gdb for a VMS target ?
> >
> > I seriously doubt that gdb will work on VMS, unless someone have
> > ported gdb. And this requires a more complex form of porting than just
> > getting the compiler to accept the source, and the libraries to be
> > available with the right functions.
> >
> > gdb, but its very nature, requires to understand more of the internal
> > plumbing of VMS. Or else how do you expect it to know how to force a
> > program to stop at some breakpoint, examine different threads, resume
> > execution, install trap vectors for different issues, catch those
> > traps and do something, possibly attach to other processes, single
> > step code... The list goes on. This is a way different level of
> > porting than most other things.
> 
> Have a look at:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gdb/stubs/ia64vms-stub.c;hb=HEAD

Welcome to comp.os.vms, thank you for joining in.

I was actually thinking of mentioning the gdb stub 
concept (not necessarily in the IA64 context, just 
in the context of splitting "host" from "target"). 

However, my own gdb stub experience is deep in the 
mists of time, you're probably a bit more up to date ;)

The other thing I might mention while you're here 
relates to John Reagan's recent comment that 
DWARF is DWARF.

That is true in so far as it goes, but my GNATty 
experience (almost a decade ago) was that DWARF 
rules and formats were used, but in a way that wasn't 
helpful to the outsider wishing to develop their own 
tools that relied solely on debug info from DWARF.


For example back then there would be some 'spurious' 
symbols in the DWARF-from-Ada which were existing symbol
names which had been mangled to encode various attributes 
which couldn't have been done in DWARF's predecessor, STABs. 

The attribute encoding (array bounds etc?) could often 
have been done in pure DWARF without the manglecoding.

Without a magic decoder ring or years of reverse 
engineering, these manglecoded things were a hindrance 
rather than a help for my needs at the time (which, 
strangely enough, related to debug and test tools), and 
the readily availabe source for bits of gdb and gcc/gnat 
wasn't all that helpful to me.

So, back to John Reagan's comment: for the current 
implementation, is a magic decoder ring still needed, 
or is pure DWARF pretty much sufficient?

Once again, thank you, and welcome to comp.os.vms

Have a lot of fun.