Tracing tool - JavaScript ServiceList

Compare that to the ‘JavaScriptServiceList’ module, which was a way of trapping RISC OS interfaces (vectors, SWIs, events, services, etc) and using a scripting language to debug them.

(quoting myself from another thread)

… clearly if you’re going to be allowing something to hook into every part of the operating system, JavaScript is the language to use. It’s just obvious isn’t it? It’s not completely insane in any way.

(quoting myself from http://gerph.org/riscos/ramble/testingdebugging-2.html#JSSL)

My friend Chris was having fun debugging what’s going on with file paths, so I suggested that maybe JSSL might be able to help with that. I spoke a little about this in the Rambles (linked above) but I don’t think it ever went to more than a few people for playing with. It turns out that it didn’t compile on my system any more, and wasn’t 32bit safe (though handily had an `ASSERT {CONFIG} = 26` to warn me)… And it was just one veneer routine and it was very simple to fix.

Example run on my system:

*help servicelist
==> Help on keyword 'ServiceList' (Module)
Module is: ServiceList     2.08 (30 Apr 2020) C+JS version
.
Commands provided:
  ServiceList_Info        ServiceList_Script
*servicelist_info
This module incorporates the Mozilla JavaScript engine. Sources for the
engine can be obtained upon request. This is beta test software and because
of this, the source is a little more closed than it ought to be according
to MPL 1.1 clause 3.2.
.
The Mozilla JavaScript engine was initially developed by Netscape
Communications Corporation, and is now maintained and developed by the
Mozilla community.
.
Engine: JavaScript-C 1.5 pre-release 5a 2003-05-29
*servicelist_script fileops/js
*load werr
OS_FSControl: 11 SetTemporaryFS load
OS_File: 255 on file werr
OS_FSControl: 11 SetTemporaryFS @LoadType_ffb
OS_FSControl: 11 SetTemporaryFS Basic
OS_FSControl: 2 
BASIC V version 1.36 © RISCOS Ltd
.
Starting with 6287612 bytes free
.
OS_File: 5 on file "$.Werr"
OS_File: 255 on file "$.Werr"
>

So I’ve built it, and it works on my version of RISC OS (which is honestly pretty freakin’ surprising to me). In the interests of following up on ‘debug tools are important’… would this be of interest to anyone? I can’t promise that it’ll work on any given system… but it worked back in ‘04, and all I’ve changed is to tweak a small bit of 32bitness. It’s utterly alpha level, and there’s huge caveats to using it – essentially you can hook many parts of the OS, so that gives you the amazing ability to blow the system away. Plus it’s hooking with interpreted Javascript, so you’ll see a little bit of a slow down.

I would expect that there are much better tools about, given that it was some years ago that I wrote it, but if there’s interest, I can probably put it somewhere for people to try.

would this be of interest to anyone?

Guess ;)

Looks like an interesting tool. It’s a shame we don’t have something equal to DiagnosticDump, but it would be a start. I like the example tracking OS_Byte use. I’m imagining that could be adapted to, say, track events or vectors or ServiceCalls?

would this be of interest to anyone?

I’m pretty sure there are plenty of software gathering digital dust on your hard disc that we would all find interesting.
I think I’m going to have a re-read of your rambles again. Lots of very interesting stuff there.
Good to hear from you.

I like the example tracking OS_Byte use. I’m imagining that could be adapted to, say, track events or vectors or ServiceCalls?

The example of counting usage is actually one of the more redundant ones, as I believe druck (or ARM Club; sorry my memory sucks) already have dedicated tools that track these, which are almost certainly more efficient and less intrusive.

According to the docs, vectors, events, services, and wimp post filters are supported, with specific handlers for spritev eventv and upcallv. I’ll dig out the examples later, and ‘cos it only builds manually I’ll need to put some CI around it – fortunately building it inside a docker container should be dead easy. Then I need to work out where to push it; I have an artifactory server that I use with my gitlab, but I don’t trust making that publically accessible.

It’s certainly helped me track an odd behavior down .. the only thing to beware of is you can’t log all your file operations to a file.. :)

I’ve decided on plain old ‘dump it into a webserver’ as a solution to the artifact storage.

• http://built.gerph.org/JSSL/

… contains a copy of the JSSL module, ‘documentation’, and whatever examples I had lying around. Chris’ tested it on a real RISC OS, so it must work. Read the caveats.

The only thing to beware of is you can’t log all your file operations to a file.. :)

Turns out that you can (I gave Chris bad information ‘cos I didn’t remember)! The interpreter code locks itself so that you don’t reenter it, so if you do write to a file whilst trapping the vectors, it’ll go through as if you weren’t there. I only discovered this whilst re-writing parts of the documentation.

Sounds like you thought of everything! :)