Reporting bugs page update

Is it me? What did I break? Or is “Where” somewhere else?

Reporting bugs
*Spool $.capture – copies any further text into a file
*Modules – outputs a big list of all loaded modules
*Where – outputs information about last serious error
*ShowRegs – outputs some internal CPU state information
*Spool – closes the text capture file

*Where
File ‘where’ not found

Preparedness is the key. Try reading the ‘Being ready for a crash’ section ;-)

Preparedness is the key. Try reading the ‘Being ready for a crash’ section ;-)

Yes, I see what you mean – the page needs a re-write to put the requirements bit much earlier

and more prominent (for those who don’t always wear their glasses.)

Preparedness is the key. Try reading the ‘Being ready for a crash’ section ;-)

I thought I’d have a play.

Seems I’m real good at breaking things.

AllSWIs – OK, DebugTest – OK

DebugTools:
mkdir -p rm
mkdir -p o
objasm -depend !Depend -throwback -o o.DebugTools Hdr.GetAll
ARM AOF Macro Assembler 4.01 (Acorn Computers Ltd) [04 Jul 2011]
You have used the uk_lowercase macro. This ONLY alters ‘A-Z’.
Use the Territory Manager for any International-aware code.
You have used the uk_lowercase macro. This ONLY alters ‘A-Z’.
Use the Territory Manager for any International-aware code.
Error: Immediate value 0×0000042C is out of range at line 189 in file s.IRQpatch
included by GET/INCLUDE directive at line 45 in file “Hdr.GetAll”
189 00002ad4 ADR R5, IRQ_code_end
Assembly terminated:
1 Error, 0 Warnings
AMU: * exit (1) *

Error: Immediate value 0×0000042C is out of range at line 189 in file s.IRQpatch
included by GET/INCLUDE directive at line 45 in file “Hdr.GetAll”
189 00002ad4 ADR R5, IRQ_code_end

The IRQ_code_end pointer is too far away from the ADR instruction. ADR works by ADDing or SUBing R15 to get a pointer to “over there”, and as such it falls to the same restrictions as ADD and SUB in what values can be directly provided.

Try changing ADR to ADRL – I don’t recall if objasm does ADRL, but worth a try at least. That will synthesise the same thing over a greater range by using another instruction (or two).

Try changing ADR to ADRL

When I have time – long day today (project planning for my nice new network) and tomorrow starts at 4am for a required change on the existing network.

Try changing ADR to ADRL

Yup that fixes it. Working module output.

Jeffrey – small change required to the CVS source.

BTW. Any reason we don’t have DebugTools in the HardDisc4 build for everyone to use? At 13k it isn’t stressing memory even if it is always loaded.

Off to bed.

It has been suggested in the past (By me amongst others) that ‘Where’ is included in the RISC OS ROM.
IIRC last I suggested it there were other things I thought should be included: but maybe not Who/What/Why & When:-)

Edit. After searching through over 20 pages of my postings I’ve found my last posting about ‘Where’ and it was ‘Which’ and ‘Here’ See https://www.riscosopen.org/forum/forums/11/topics/2436

An excellent idea – I second this suggestion (again).

It has been suggested in the past (By me amongst others) that ‘Where’ is included in the RISC OS ROM.

DebugTools has a bit more than just “where”:

Module info
===
Generated by : !Verma 0.27 (03 Dec 2008)
Generated on : Tue 07 Oct 2014. 08:49 PM

Title : DebugTools
Help : Debug Tools 1.17 (14 Jan 2012)

Flags :
32-bit ready : Yes

No Service handlers provided by this module.

SWIs :
&554C0 DebugTools_AddressInfo
&554C1 DebugTools_Where
&554C2 DebugTools_Vectors
&554C3 DebugTools_Tickers
&554C4 DebugTools_IRQDevices
&554C5 DebugTools_IRQInfo
&554C6 DebugTools_UnknownIRQs
&554C7 DebugTools_ClaimOSSWI
&554C8 DebugTools_AddToOSSWI
&554C9 DebugTools_ReleaseOSSWI

Commands :
X
Where
Vectors
Tickers
IRQDevices
IRQInfo
Canonical
UnknownIRQs
RMDie
RMRemove
PushD
PopD
PWD
EvalHex
EvalBin
RMSave
SaveWorkspace
SaveDA
RemoveDA

An excellent idea – I second this suggestion (again).

Not the DebugTools option then? Seems far more useful.

Only because it is something that we want any user to be able to do when reporting a problem.

Only because it is something that we want any user to be able to do when reporting a problem

And the other debug tools in DebugTools along with Where are not?

If it is in the ROM, then any user will get a response by typing ‘where’. The debug tools are a paid-for upgrade from ROOL on the C/C++ pen drive?

The debug tools are a paid-for upgrade from ROOL on the C/C++ pen drive?

Source code pointed to by link on Reporting bugs page feel free to compile it.
RISC OS 5.20 is a paid for item on SD card on ROM etc, or you can download it as an image or you can download the source and compile it yourself.

NB. Many people buy either to support the work or because they want a ready to go item.

Not the DebugTools option then? Seems far more useful.

I think the ADR→ADRL should have set off alarm bells, as I assume you were building it in a ‘Disc’ environment where some of the macros expand to account for 26 or 32 bit operation. The alarm bell being that it’s probably never been tested in that situation, or at the very least it’s been gathering dust for a while.

A cursory glance at the sources show other crimes, such as poking timer 0 in IOMD, a hardwired limit of 64 interrupts, and it’s not internationalised – so it’ll need some work to make it ROMmable standard. Even fixing those up leaves me uneasy about everyone having a module loaded that intercepts the SWI and IRQ vectors (to do stats gathering), so I think DebugTools is probably a power user/load when you know you want it.

The page has a link to how to get the ‘Where’ utility and suggests a suitable installation place, and it’s a pretty handy command for anyone using RISC OS. There is some merit in adding that alone (perhaps to the Debugger module where *SHOWREGS is?) at some point in the future, if only to allow you to use it if FileCore has been trodden on.

Try reading the ‘Being ready for a crash’ section ;-)

Yes, I see what you mean – the page needs a re-write to put the requirements bit much earlier

I don’t think the order does need changing. It uses the standard recipe format

• What flavour cake are we making?
• What are the ingredients?
• What order do you mix things?
• How long to bake for?
• How is it best served?

but as Jeffrey says, it does require reading all of the words that are written. Hopefully this thread might prompt some better bug reports too – that page hadn’t been touched since 2008 and had some defunct references to a downloads page, as well as being a bit confused about reporting bugs to ROOL versus other application authors.

as I assume you were building it in a ‘Disc’ environment

Yup.

Hopefully this thread might prompt some better bug reports too

Glad I did something useful. Can but ask questions.

A cursory glance at the sources show other crimes, such as poking timer 0 in IOMD, a hardwired limit of 64 interrupts, and it’s not internationalised – so it’ll need some work to make it ROMmable standard. Even fixing those up leaves me uneasy about everyone having a module loaded that intercepts the SWI and IRQ vectors (to do stats gathering), so I think DebugTools is probably a power user/load when you know you want it.

DebugTools does a lot of naughty things – many of which had no better way available at the time of writing it. I actually added various features to the Kernel as I wrote it to try to reduce just how many awful hacks it was having to do. But it’s not really been looked at since (and I wrote it probably around 15 years ago for some very specific use cases) so I bet there are lots of better mechanisms available to do some of what it does.

I tend to agree with Rob that this is a power user tool and overkill for a ROM anyway. A small subset of DebugTools features in a ROM module might not be such a bad idea though. Maybe a build option?

As an aside, I still believe the ClaimOSSWI, AddToOSSWI, ReleaseOSSWI calls are something that could/should be in the OS – RISCOS Ltd implemented a version of these and I believe some of the Kernel’s SWI chunk is set-aside to them. My implementation in DebugTools is (IIRC) not API compatible with the ROL calls but (IMHO) much better – it’s vectorised, for one thing.

Steve: What is the problem with including things like ‘Where’ in all builds?
I can see why Debug tool is inappropriate but can’t see any downside for things like ‘where’.
Also from a support point of view having ‘Reporter’ installed in all disc builds with an easy way of turning it on and the level of reporting would be so useful.

Steve R may say the same, but I believe the issue is simply that the standalone Where is copyright of Druck. If he explicitly gives permission (and there’s no GPL code) it’s all OK, otherwise no inclusion.

I can see why Debug tool is inappropriate but can’t see any downside for things like ‘where’.

ROOL’s Where is part of Debug, so you’d need to split that bit out. Which I think is what Steve said.

the standalone Where is copyright of Druck

Andy Armstrong, surely?

Andy Armstrong, surely?

Ah, so it is – 32 bitted by druck only.