ada archives and debug

[gérard Calliet]

As someones here know, I have built a GNAT Ada compiler on VMS itanium
Everyone can get it for free here: www.vmsadaall.org
(very "sober", I had no time to do more)

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.

I have 2 questions:
- are there existing "archives" on that issue, questions, tries...
- how much effort such a project could involve

Every idea will be wellcomed

Gérard Calliet

[Simon Clubley]

On 2018-01-18, gérard Calliet <gerard....@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 never got as far as trying to build gdb for VMS so I don't know
what the situation is with gdb on VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[gérard Calliet]

Le 18/01/2018 à 19:44, Simon Clubley a écrit :
> On 2018-01-18, gérard Calliet <gerard....@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 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.

[Simon Clubley]

On 2018-01-18, gérard Calliet <gerard....@pia-sofer.fr> wrote:
> Le 18/01/2018 à 19:44, Simon Clubley a écrit :
>> On 2018-01-18, gérard Calliet <gerard....@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 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 ?

[gérard Calliet]

Le 19/01/2018 à 15:07, Simon Clubley a écrit :
> gdb_is_ multi-language.
The customer I know use solely the VMS debugger, but why not try.

>
> Have you tried using the Adacore supplied version to see if it can
> debug programs written using a mixture of languages ?

Adacore *doesn't* supply a compiler for VMS, my problem :)
But, again, why not trying a free package on other platforms.

Gérard Calliet

[Craig A. Berry]

On 1/19/18 8:07 AM, Simon Clubley wrote:
> On 2018-01-18, gérard Calliet <gerard....@pia-sofer.fr> wrote:
>> Le 18/01/2018 à 19:44, Simon Clubley a écrit :
>>> On 2018-01-18, gérard Calliet <gerard....@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 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.

As far as I know (and I'm no expert) the information he needs is not
publicly available and would require the cooperation of VSI, access to
source code, or a lot of trial and error with analyzing object code.

Here's an interesting article on the general (not VMS-specific) topic
with further references:

<https://www.ibm.com/developerworks/library/os-debugging/>

[Stephen Hoffman]

On 2018-01-18 19:28:04 +0000, g rard Calliet said:

> Le 18/01/2018 à 19:44, Simon Clubley a écrit :
>> On 2018-01-18, gérard Calliet <gerard....@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 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.

Ada would need to be updated to generate the debug record formats, and
there'd need to be some support integrated into the debugger.

I placed a copy of the then-current debugger symbol table and related
stuff on OpenVMS Freeware V5.0.
http://www.digiater.nl/openvms/freeware/v50/debug/ IIRC, binutils
has some related support, too.

Itanium integration would be somewhat easier, as the more common ELF
and DWARF formats are used on OpenVMS I64. There'd probably be some
need to update for any VMS-isms in that, and work in the debugger to
add support for Ada there.

This is not a weekend project, by any stretch. It'll very likely
require OpenVMS source code, too.

AFAIK, there aren't any language-specific plug-ins in the OpenVMS
debugger. Though that'd be a nice addition, if VSI doesn't decide to
punt on the traditional debugger in the longer-term, and migrate to and
use lldb for future work.

As for debuggers, I've become fond of the ability of lldb to be scripted.

And the Apple macOS Xcode IDE integration with the debugger completely
blows away anything I've seen available or have used on OpenVMS;
integrated or third-party.

For this project, you're undoubtedly going to end up using two
debuggers, as the only alternative is debugging the unsupported
language(s) from machine code in the other of the two debuggers.




--
Pure Personal Opinion | HoffmanLabs LLC

[Simon Clubley]

On 2018-01-19, gérard Calliet <gerard....@pia-sofer.fr> wrote:
> Le 19/01/2018 à 15:07, Simon Clubley a écrit :
>> gdb_is_ multi-language.
> The customer I know use solely the VMS debugger, but why not try.
>>

In which case you have a problem. I doubt you are going to be able
to modify the VMS Debugger if it doesn't already do what you want.

>> Have you tried using the Adacore supplied version to see if it can
>> debug programs written using a mixture of languages ?
> Adacore *doesn't* supply a compiler for VMS, my problem :)

I was talking about trying the gdb version in the original GNAT Pro
toolchain you used to build your Itanium toolchain.

If it doesn't work with a binary built with multiple compilers then
there's no point in going further. If it does, then you have to
decide if it's worth the effort trying to get some version of gdb
compiled for Itanium.

[Simon Clubley]

On 2018-01-19, Craig A. Berry <craig...@nospam.mac.com> wrote:
> On 1/19/18 8:07 AM, Simon Clubley wrote:
>>
>> 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.
>

I honestly don't know which is why I suggested he setup a test to try it.

I do know that at the lower structural levels, there is some compatibility
between the native VMS tools and the binutils versions I tried and there's
clearly been some effort to make libbfd and some of the tools built around
it compatible with the VMS tools.

For example, I found that the same file formats were used for the VMS
Alpha binutils librarian and the native VMS librarian (although there
are some VMS Alpha specific bugs in the FSF version of binutils.)

I have no idea however how much the compatibility extends to the code
and standards layered on top of these structures when it comes to
multi-language/multi-compiler support and debugging programs.

[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

[John Reagan]

On Friday, January 19, 2018 at 11:06:17 AM UTC-5, Stephen Hoffman wrote:

>
> Itanium integration would be somewhat easier, as the more common ELF
> and DWARF formats are used on OpenVMS I64. There'd probably be some
> need to update for any VMS-isms in that, and work in the debugger to
> add support for Ada there.
>

Since most of the debugger is common code between Alpha and Itanium, there is already lots of "lang=ada" support in the debugger. The debugger converts either the Alpha DSTs or the Itanium DWARF into a common internal format. I haven't looked a the DWARF to RST conversion to see what it might do with anything specifically Ada'ish like PACKAGES and the like.

[Johnny Billquist]

On 2018-01-18 19:44, Simon Clubley wrote:
> On 2018-01-18, gérard Calliet <gerard....@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.

> I never got as far as trying to build gdb for VMS so I don't know
> what the situation is with gdb on VMS.

Like I said, unless someone actually have *ported* it, I'd say this end
is deader than a dead horse.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Tristan Gingold]

Johnny Billquist <b...@softjar.se> writes:

> On 2018-01-18 19:44, Simon Clubley wrote:
>> On 2018-01-18, gérard Calliet <gerard....@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

[Simon Clubley]

On 2018-01-19, Johnny Billquist <b...@softjar.se> wrote:
> On 2018-01-18 19:44, Simon Clubley wrote:
>> On 2018-01-18, gérard Calliet <gerard....@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.
>

Huh ???

What do you think Adacore were using for their compiler toolchain on VMS ?

The question here is whether the Adacore gdb will support binaries
created using the normal VMS compilers as well as those created
using gcc.

That's something I simply don't know the answer to which is why
I suggested that Gerard setup a test with his existing GNAT Pro
compiler to find out.

[johnwa...@yahoo.co.uk]

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.

[Tristan Gingold]

johnwa...@yahoo.co.uk writes:

> On Saturday, 20 January 2018 07:13:16 UTC, Tristan Gingold wrote:
> The other thing I might mention while you're here
> relates to John Reagan's recent comment that
> DWARF is DWARF.

Yes, DWARF is DWARF and DWARF is complex.
There are many DWARF constructs (like locations list) that
aren't handled by VMS DEBUG.

It was still possible to debug Ada compiled by gcc 4.7 on VMS
but the experience wasn't great.

Using a cross-gdb for VMS is the simplest solution from a tool
point of view, but then support for multiple language is not
that great.

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

True.

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

True.

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

You should now have a decent experience with pure DWARF.

[Scott Dorsey]

Johnny Billquist <b...@softjar.se> wrote:
>> 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.

I remember back in the late 1980s there being a vax port of gdb, which
you had to use with code compiled with gcc. If you compiled with gcc
you could debug with gdb, but if you compiled with vax c you had to use
DEBUG. But DEBUG didn't work with gcc. It was generally awful.

But somebody at some point did make the attempts to port.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[John Reagan]

On Saturday, January 20, 2018 at 6:34:50 AM UTC-5, johnwa...@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.

[gérard Calliet]

Le 19/01/2018 à 17:06, Stephen Hoffman a écrit :
> This is not a weekend project, by any stretch.

My weekend answer: great thanks for this discussion, and all the ideas
and links, and I say that for all contributors.

So: next 6 days to read all I can, next 6 months to do the job, and one
more idea a day in this thread.

I needed intuitions on feasibility. I got them. It seems it is a complex
project, but not impossible.

I go back with more technical issues as soon as I can.

Before the complete project will be available, everyone can download the
compiler (www.vmsadaall.org) as it is for VMS Itanium, try it, criticize it.

It is now a (somehow) poor solution.
(I had to have a compiler rebuilt for a port from DEC Ada (alpha) to
Itanium, and Adacore gave up the support just before the beginning of
the project. The solution you can get is a rapid rebuild from FSF
sources. A lot of work has to be done now, for example about packaging,
and integration of integration tools (like GNAT shop).)

Thanks again,

Gérard Calliet

[Jan-Erik Soderholm]

Question is, would the customer/user rather move away from OpenVMS
rather then move away from Ada (and stay on OpenVMS)?

Unfortunately, it is this kind of "issues" that might push custumers
away from OpenVMS.

[gérard Calliet]

Le 21/01/2018 à 00:22, Jan-Erik Soderholm a écrit :
> Question is, would the customer/user rather move away from OpenVMS
> rather then move away from Ada (and stay on OpenVMS)?
>

The customer I "saved" from going away from VMS use my GNAT Ada build on
VMS. He wants now more comfort.

> Unfortunately, it is this kind of "issues" that might push custumers
> away from OpenVMS.

You are right. Adacore says they have closed the last VMS support
contracts this year: the customer have moved away from VMS to keep Ada,
and some have moved away from Ada *and* VMS (for example rewritting on
Java). (I'm already too late, except for customers on DEC Ada Alpha,
whom noone knows).

In a sense, VMS and Ada are on the same boat: old great technologies,
and, as "business is businness", better scutling the boat than taking
time to think about sustainability.
(I had a picture on that, when I went round Europe in 2013, remember?).

Gérard Calliet

[Johnny Billquist]

On 2018-01-20 11:40, Simon Clubley wrote:
> On 2018-01-19, Johnny Billquist <b...@softjar.se> wrote:
>> On 2018-01-18 19:44, Simon Clubley wrote:
>>> On 2018-01-18, gérard Calliet <gerard....@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.
>>
>
> Huh ???
>
> What do you think Adacore were using for their compiler toolchain on VMS ?

The VMS debugger?

If gdb have been ported, then we're all good. I'm just saying that if
someone is thinking of porting gdb, it is a way more complicated thing
than just getting it through a compiler.

[Stephen Hoffman]

Hence the "somewhat easier". Color me skeptical on complete cross-tool
compatibility, though. I'd expect OpenVMS filename syntax to require
some work in gdb and/or lldb and some work in the OpenVMS debugger when
(if) that gets handed a Unix path, at the very least. And there are
almost certainly other differences latent here. In the absence of
commonly-accepted tools for syntax and constants and file format
verification and sometimes even with such, there are always wrinkles in
the interpretations and implementations. ELF is common too, but there
are some OpenVMS differences (extensions) in the OpenVMS I64
executables that are written in that scheme. Any Ada compiler
generating code either via gcc or via dragonegg or otherwise would
almost certainly need work.