push {}

[cfbsoftware]

No precise ETA yet - but should be in 2019.

Unfortunately we have had to delay this release but now hope it will be ready in Jan 2020. I apologise for any inconvenience caused.

Here is a preview of the work done so far:

[gray]

In the screenshot, the disassembler does not show the Oberon source lines, while the current module-based disassembler does. Is this a functional limitation of the new disassembler, or a display option?

[cfbsoftware]

It is a functional limitation.

Note that the Application disassembler does not replace the Module disassembler - they are separate menu items:

ProjectMenu.jpg (9.960000000000001 KiB) Viewed 50062 times

They are both implemented very differently. The Module disassembler requires the source code and compiler to be present; the Application disassembler requires neither.

[gray]

The stack trace code I had described here does not work with leaf procedures. The procedure calling the leaf procedure is not detected as the leaf procedure does not create its own stack frame. I have yet been unable to come up with a solution as I fail to find a reliable method to detect a leaf procedure from within an error exception handler.

Do I miss anything, possibly the obvious?! Any hint how to detect a leaf procedure from an exception handler?

Will the stack trace in the forthcoming new version of Astrobe support leaf procedures?

Thanks.

[cfbsoftware]

Any hint how to detect a leaf procedure from an exception handler?

This was the best we could come up with:

Code: Select all

    SYSTEM.GET(id.addr + 4, id.lineNo);
    (* Not a valid line number:  a leaf procedure, adjust address *)
    IF BFX(id.lineNo, 31, 16) # 0 THEN 
      id.addr := id.addr + 4;
      SYSTEM.GET(id.addr + 4, id.lineNo)
    END;

Will the stack trace in the forthcoming new version of Astrobe support leaf procedures?

Yes.

[gray]

In the code snippet, is id.addr still set to the same value as with the current Astrobe version, ie. the return address as pushed by the processor upon exception entry? And does the compiler/linker still write the source code line number as four byte value at the address right after the svc instruction?

[cfbsoftware]

Because of your contributions to this exercise, I've sent you a preview copy by separate email of the updated v7.1 version of Traps.mod for you to experiment with.

[gray]

Thanks!

Which reminds me of a question I had meant to ask for some time: Traps.mod has handlers for faults such as mem fault or bus fault, but I cannot find the location where the corresponding system handlers get enabled (register SCB_SHCSR, defaults to handlers disabled). Is this by design, or do I miss something?

[cfbsoftware]

Not by design and you didn't miss anything either. I wasn't aware of this - do you know of any reason why they are disabled by default? The following example code shows one way they could be enabled:

Code: Select all

CONST
  NVIC_SHCSR = MCU.NVICBase + 0D24H;
  
VAR
  x: INTEGER;

Code: Select all

  SYSTEM.GET(NVIC_SHCSR, x);
  BFI(x, 18, 16, 07H);
  SYSTEM.PUT(NVIC_SHCSR, x);

[cfbsoftware]

Here's an example of how to test the trapping of UsageFault errors:

Code: Select all

MODULE TestTraps4;

IMPORT Main, Out, SYSTEM;

VAR
  p: PROCEDURE;
  x: INTEGER;
  
PROCEDURE P1();
BEGIN
  Out.String("ok"); Out.Ln()
END P1;

BEGIN
  P1();
  SYSTEM.PUT(SYSTEM.ADR(p), SYSTEM.ADR(P1) + 1);
  p()
END TestTraps4.