[Info-vax] ada archives and debug

[John Reagan]

On Friday, January 19, 2018 at 10:50:46 AM UTC-5, Craig A. Berry wrote:
> On 1/19/18 8:07 AM, Simon Clubley wrote:
> > On 2018-01-18, gérard Calliet <> wrote:
> >> Le 18/01/2018 à 19:44, Simon Clubley a écrit :
> >>> On 2018-01-18, gérard Calliet <> 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 don't know about gdb. The need is being able to use VMS standard debug
> >> in a context of multi-langage images (pascal calling Ada calling C ...)
> >> where VMS calling standard and VMS debug are just fine.
> > 
> > gdb _is_ multi-language.
> > 
> > Have you tried using the Adacore supplied version to see if it can
> > debug programs written using a mixture of languages ?
> 
> So you're saying the DWARF information produced by a GCC compiler and
> the DWARF information produced by a native VMS compiler are compatible
> and interchangeable? I'm skeptical. If that were true, then people could
> just use the VMS debugger with the GNAT-produced images.

DWARF is DWARF.  GEM generates DWARF 2 compatible info with a few things from DWARF 3 that were cherry picked.  GEM claims DWARF 3 in the debug info.  

The symbolic debugger was only tested with the DWARF 2/3 that GEM generates.  Not with some sort of full DWARF 2 compliance tester.

I just did a PASCAL/DEBUG/NOOPT on my Itanium system, ftp'd the object over to my x86 CentOS system, and did a "objdump -g jrr.o" and got a valid DWARF dump.

$ objdump -g jrr.o
...
The File Name Table:
  Entry	Dir	Time	Size	Name
  1	0	50096976664882838	332	WORK20:[JREAGAN]JRR.PAS;5

 Line Number Statements:
  Extended opcode 128: DW_LNE_HP_source_file_correlation
    DW_LNE_HP_SFC_formfeed
    DW_LNE_HP_SFC_associate (1,1,11)
  Extended opcode 2: set Address to 0x0
  Copy
  Special opcode 197: advance Address by 17 to 0x11 and Line by 6 to 7
  Advance PC by 48 to 0x41
  Special opcode 5: advance Address by 0 to 0x41 and Line by 1 to 8
  Special opcode 181: advance Address by 16 to 0x51 and Line by 1 to 9
  Advance PC by 96 to 0xb1
  Special opcode 5: advance Address by 0 to 0xb1 and Line by 1 to 10
  Advance PC by 48 to 0xe1
  Special opcode 5: advance Address by 0 to 0xe1 and Line by 1 to 11
  Advance PC by 47 to 0x110
  Extended opcode 1: End of Sequence
...
Contents of the .trace_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x45 (32-bit)
   Version:       3
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_stmt_list   : 0x0
    <10>   DW_AT_low_pc      : 0x0
    <18>   DW_AT_high_pc     : 0x110
    <20>   DW_AT_HP_unit_name: FOO
    <24>   DW_AT_language    : 32773	(implementation defined: 8005)
    <27>   DW_AT_producer    : VSI Pascal I64 V6.2-125
 <1><3f>: Abbrev Number: 2 (DW_TAG_subprogram)
    <40>   DW_AT_name        : FOO
    <44>   DW_AT_low_pc      : 0
    <45>   DW_AT_high_pc     : 272
 <2><47>: Abbrev Number: 0
 <1><48>: Abbrev Number: 0

> 

www.dwarf.org for the standards.  For the values of the various DW_AT_HP tags in the extension range, you'd need that info elsewhere.  

https://github.com/gcc-mirror/gcc/blob/master/include/dwarf2.def
https://github.com/gcc-mirror/gcc/blob/master/include/dwarf2.h