[Info-vax] ada archives and debug

[John Reagan]

On Saturday, January 20, 2018 at 6:34:50 AM UTC-5, johnwa... at yahoo.co.uk wrote:

> 
> 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?
> 

We generate just DWARF within the DWARF guidelines.  As I mentioned, we use some vendor-specific tags, etc.  Some of them are "extensions" in DWARF 2 but become part of DWARF 3.

As Tristan mentions, DWARF can be complex. There can be many tags on variables, routines, etc that may or may not be supported or understood by the system debugger.  I had the same experience when I worked with the port of NonStop to x86.  The open64 backend didn't generate the tags that the NonStop debugger had been expecting.  That debugger "grew up" with the Intel Itanium DWARF output and had some implicit dependencies on certain tags.  I spent months getting the COBOL DWARF "just right" to make the debugger tests get the identical results as NonStop on Itanium.  Just thinking about COBOL LEVEL 88 conditional names again....

Yes, GEM on Itanium doesn't generate location lists.   Which means the VMS debugger never saw them or had to deal with them (at least with GEM based compilers).  DWARF location lists often are generated with you generate debug information for optimized code.  That is why we always recommend using /NOOPT with /DEBUG.  LLVM has limited location list support but it has some so I expect that we'll need to enhance our DWARF reading code.  It should accept them or at least not get upset.

I still think our debugger doesn't do the right thing with DW_AT_byte_size, DW_AT_bit_size, and DW_AT_bit_offset (used by Pascal for odd-sized fields inside of PACKED RECORDs).  But then again, they were poorly defined in the DWARF standard (I submitted a "bug report" to the dwarf committee years ago on that and they revised their wording).  There are also lots of DWARF tags for things like visibility, etc. that are probably ignored today but would be needed if the UI had better support for languages that had that concept (like Ada)

As for trying to adapt and use lldb, I've spoken to the lldb folks, we've talked about internally at VSI.  However, as Tristan/Hoff have mentioned, debuggers have to get in the mud with the OS to deal with architecture features, OS features, etc.  And then mix in the desire to support things like Eclipse, etc. makes it more complicated.  We will come back and revisit this but I suspect that V9 will ship with the traditional VMS debugger enhanced to deal with better DWARF and probably for the additional C++ language features from C++11, C++14, etc.  That is where moving to something like lldb would be a huge win - but lldb has poor support for BLISS or BASIC :)  lldb is very scriptable and relies heavily on Python.