On 2021-06-03 00:48:33 +0000, Arne Vajh j said:
> On 6/2/2021 5:02 PM, Craig A. Berry wrote:
>> On 6/2/21 8:08 AM, Arne Vajhøj wrote:
>>> On 6/1/2021 9:34 PM, Craig A. Berry wrote:
>>>> On 6/1/21 12:33 PM, Stephen Hoffman wrote:
>>>>> On 2021-06-01 15:27:34 +0000, Marc Van Dyck said:
>>>>>> Don't you do that with Source Code Analyzer, for languages that support it ?
>>>>> I use DECset SCA and PCA only rarely, as few sites have licenses for
>>>>> that. Which means using symbol tables and maps, and the debugger,and
>>>>> preferably refactoring where permitted.
>>>> And as far as I remember PCA doesn't work on shareable images, which
>>>> means on any kind of application with a semi-modern architecture, you
>>>> either do without
Last I looked, DECset PCA does have support for shareable images, but
it has long reminded me of the debugger in that regard; of having to
treat the image pieces ~separately, and not as parts of the same app.
The debugger was long one of the still-remarkable pieces of the OpenVMS
development platform, but other platforms have reached parity with or
have surpassed the debugger in recent years.
macOS with Xcode and Instruments utterly blows away the DECset
performance-related and memory-related tooling, for instance.
>>> Would it ignore the time spent in the shareable image or would it just
>>> count it as being spent in the calling code?
>> IIRC, it counts it all as being in the calling code.
> That makes sense.
It made sense in the last millennium on a VAX and with ~30 bits of
address space for apps and tooling. Now? Not so much.
Now? Treating shareable images separately is just dumb. Can you
symbolicate each piece? Show it. No symbols? Display what you can. And
get better at reversing executable images when symbols are unavailable.
q.v. Ghidra, for reversing.
>>> The latter may be good enough for many purposes.
>> Not when you have a tiny bootstrap program that loads a library to do
>> all the heavy lifting -- then it tells you that 99.9999% of the time
>> was taken by the one routine that loads the library. I believe this is
>> a fairly common architecture; it's certainly one way to make a package
>> that can be run standalone but also be embedded in other programs.
> If you need you application to be both standalone and embeddable then
> that is what you have to do.
> I don't know how common it it.
Having an app that can build both as standalone monolithic and as
shareable images is vanishingly rare. One of the very few apps around
that (sort of) does do this is SQLite.
Breaking up apps into callable hunks and into UI or networking or web
other app-specific pieces is ubiquitous, of course. Those hunks get one
or more object libraries, and the shareable images for deployment. Get
the shareable image hunks working separately, build test harnesses for
each hunk, and re-use the hunks across various executables, and update
the hunks as needed. These hunks of code can be created for various
purposes; to ease and isolate and modularize app development, for
porting to some new UI, or for porting code to another platform
OpenVMS developer tooling needs help. What the Visual Studio Code IDE
provides is a start. More work is needed for the tooling, and for VSC.
It'd be interesting to see the changes and the rate of change, were VSI
to integrate with and encourage the use of VSC internally, too.
Downside of development tooling, of course: developers can have decades
of investments in a specific set of tooling, and changing tooling (from
edit-compile-link-debug-command-line, or from some other IDE) is no
small investment of time and focus and effort. Ah well. But I digress.
"Time to re-launch Xcode for this coding project", Hoff said swiftly.