etv_term vector

GFA, ASM, STOS, ...

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

etv_term vector

Postby simonsunnyboy » Thu Nov 16, 2017 4:46 pm

Quoting from the toshyp:

"etv_term LONG 0x408 Logical GEMDOS vector 258. Should always be set via Setexc. Programs that hook into any system vectors should also hook into this vector. If the program is terminated in an abnormal manner, the operating system jumps first via this vector, so that one can withdraw cleanly from all changed vectors. As MagiC uses its own etv_term vector for each application, collisions can not arise there."

Do the default exception handlers of TOS and EmuTOS obey this handler, e.q. jump through this one? Or does only a clen process termination trigger this?
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 685
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: etv_term vector

Postby mfro » Thu Nov 16, 2017 7:11 pm

simonsunnyboy wrote:...Do the default exception handlers of TOS and EmuTOS obey this handler, e.q. jump through this one? Or does only a clen process termination trigger this?


If you are asking if every possible crash would ensure etv_term() get's called, the answer is: yes, it should ;) - everything else would potentially produce lost handles (files left open) and/or GEMDOS memory leaks. And yes, literally all GEMDOS versions prior to TOS 1.04 suffered from such (some more, some less).

To my knowledge, EmuTOS should have that right, however.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Thu Nov 16, 2017 7:18 pm

Code: Select all

marndt@silentbox:~/Projects/external/EmuTOS$ grep -r "etv_term" *
bdos/proc.c:    etv_term();
bios/bios.c:    etv_term = just_rts;
bios/tosvars.S:        .globl  _etv_term
bios/tosvars.S:_etv_term:      .ds.l   1       // GEM program termination vector
bios/tosvars.h:extern void (*etv_term)(void);
doc/bios.txt:         etv_term (long) $408
doc/changelog.txt:  never called (hdv_init, hdv_boot, etv_term, etv_critic). Is it a bug? (LVL)
doc/changelog.txt:- BDOS: implement etv_term()
emutos.map:                0x0000000000000408                _etv_term


From grepping through EmuTOS sources (a few week old snapshot on my harddisk), it seems only to be called from Gemdos process termination.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

czietz
Hardware Guru
Hardware Guru
Posts: 480
Joined: Tue May 24, 2016 6:47 pm

Re: etv_term vector

Postby czietz » Thu Nov 16, 2017 7:24 pm

Yes, etv_term is called by Pterm. Your point being? Look what happens after displaying an exception: https://github.com/emutos/emutos/blob/c ... int.c#L586

mikro
Atari God
Atari God
Posts: 1308
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: etv_term vector

Postby mikro » Thu Nov 16, 2017 10:56 pm

Wow, I have never heard about this one before and it sounds like a totally useful thing! Does this applies also to exceptions? I mean if an app tries to access hardware or causes memory violation, will this vector still be called?

ThorstenOtto
Captain Atari
Captain Atari
Posts: 177
Joined: Sun Aug 03, 2014 5:54 pm

Re: etv_term vector

Postby ThorstenOtto » Fri Nov 17, 2017 12:26 am

mikro wrote:Does this applies also to exceptions? I mean if an app tries to access hardware or causes memory violation, will this vector still be called?


Yes, it's done as part of process termination, which is also called on uncaught exceptions (see the source Christian quoted, kill_program at the end will just call Pterm()). Even Ptermres() will call this.

mikro
Atari God
Atari God
Posts: 1308
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: etv_term vector

Postby mikro » Fri Nov 17, 2017 2:57 am

But this is totally awesome! How come so few apps use it? Just a few days ago someone asked on the mint mailing list how come NetSurf takes down the whole OS on a memory violation exception. Well, because it's not using this vector to restore its IKBD handlers!

Does it work properly also in FreeMiNT? (I mean the explicit note about Magic having it for each app separately).

ThorstenOtto
Captain Atari
Captain Atari
Posts: 177
Joined: Sun Aug 03, 2014 5:54 pm

Re: etv_term vector

Postby ThorstenOtto » Fri Nov 17, 2017 4:14 am

mikro wrote:Does it work properly also in FreeMiNT? (I mean the explicit note about Magic having it for each app separately).


Never tried in practice, but i think it should. Just make sure you to use Setexc() to install the vector, not just switching to Super() and install the vector by hand.

mikro wrote:Just a few days ago someone asked on the mint mailing list how come NetSurf takes down the whole OS on a memory violation exception. Well, because it's not using this vector to restore its IKBD handlers!


I didn't look yet how NetSurf does this (i just wonder why they need to do that at all), but of course it's not that easy to cleanly uninstall the IKBD vectors in a multi-tasking environment, especially if there are other programs that might have hooked those vectors, too.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Fri Nov 17, 2017 5:26 pm

mikro wrote:Wow, I have never heard about this one before and it sounds like a totally useful thing! Does this applies also to exceptions? I mean if an app tries to access hardware or causes memory violation, will this vector still be called?


That's my use case. I would like to exploit it to execute a hook to call the Hatari native features and activate Hatari's debugger when the exception happens.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Fri Nov 17, 2017 5:27 pm

czietz wrote:Yes, etv_term is called by Pterm. Your point being? Look what happens after displaying an exception: https://github.com/emutos/emutos/blob/c ... int.c#L586


Thanks, seems the call is hidden inside EmuTOS. Does regular TOS do the same?
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Fri Nov 17, 2017 6:23 pm

I browsed the Atari ST Profibuch, atleast the 1988 edition I have lists a generic exception handler drawing bombs in assembly language, TOS 1.0 presumably. This indeed seems to call Pterm0() at the end of the bombs.

If this is in place for others, I have to test.

With EmuTOS only the wait for keypress is less attractive.

So I think all should work, and it is the place to add an atexit() handler aswell, making the thing really useful.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1563
Joined: Sun Jul 31, 2011 1:11 pm

Re: etv_term vector

Postby Eero Tamminen » Fri Nov 17, 2017 8:32 pm

simonsunnyboy wrote:That's my use case. I would like to exploit it to execute a hook to call the Hatari native features and activate Hatari's debugger when the exception happens.


Easier would be just ask Hatari to invoke debugger when exceptions happen. To do that for all exceptions, use following option:

Code: Select all

--debug-except all


Note: above option only sets mask of which exceptions should be catched, but it doesn't itself enable the catching.

Catching is toggled with the "-D" option. However, if you use that when starting Hatari, exceptions at bootup (from HW probing done by TOS) would also invoke debugger.

To avoid that, you have two options:

1. Toggle exception catching at run time from debugger with:

Code: Select all

setopt -D


(You can change which exceptions are caught at the same time with --debug-except option if you want to.)

2. Use the "autostart" Hatari option to tell exception catching to be enabled when a program is auto-started by Hatari:

Code: Select all

--debug-except autostart,all


The exceptions supported by the "--debug-except" option are listed with:

Code: Select all

--debug-except help

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Sat Nov 18, 2017 10:21 am

Yes but I also want to execute additional code to dump my program's state through the Debugger console print functions, a program specific coredump facility.

Unless you provide the Hatari debugger with the ability to list my variables correctly with datatypes and readable names ;)
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 685
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: etv_term vector

Postby mfro » Sat Nov 18, 2017 10:34 am

simonsunnyboy wrote:... So I think all should work, and it is the place to add an atexit() handler aswell, making the thing really useful...


Remember that you can't expect to (reliably) call GEMDOS functions from the etv_term vector. So its usefulness might be pretty limited.

joska
Hardware Guru
Hardware Guru
Posts: 3684
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: etv_term vector

Postby joska » Sat Nov 18, 2017 10:37 am

mikro wrote:I mean if an app tries to access hardware or causes memory violation, will this vector still be called?


IIRC Thing! use this vector to catch memory violations.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Sat Nov 18, 2017 10:38 am

mfro wrote:
simonsunnyboy wrote:... So I think all should work, and it is the place to add an atexit() handler aswell, making the thing really useful...


Remember that you can't expect to (reliably) call GEMDOS functions from the etv_term vector. So its usefulness might be pretty limited.


The output is all NATFEATS calls, I am using this from my asserts already. But I can check there is no GEMDOS involved.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

czietz
Hardware Guru
Hardware Guru
Posts: 480
Joined: Tue May 24, 2016 6:47 pm

Re: etv_term vector

Postby czietz » Sat Nov 18, 2017 10:55 am

simonsunnyboy wrote:I browsed the Atari ST Profibuch, atleast the 1988 edition I have lists a generic exception handler drawing bombs in assembly language, TOS 1.0 presumably. This indeed seems to call Pterm0() at the end of the bombs.

If this is in place for others, I have to test.


Newer TOS/GEMDOS versions call Pterm(-1) to kill a process after an exception, as you will find documented e.g. in the Profibuch. This means that the etv_term handler is also called. See this German article by Julian Reschke, where he suggests hooking into etv_term to provide the user with sort of a crash dump in case of an exception:
http://www.stcarchiv.de/stc1996/03/atarium

EDIT: For official documentation about the fact that Pterm(-1) is called in case of an exception, see p. 38 in http://dev-docs.exxoshost.co.uk/Rainbow ... 5-1991.pdf
Last edited by czietz on Sat Nov 18, 2017 10:59 am, edited 1 time in total.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Sat Nov 18, 2017 10:58 am

Exactly what I need then, I only have to hookup my existing code to the vector...
see viewtopic.php?f=51&t=29249#p293615 what I am using with slight improvements.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1563
Joined: Sun Jul 31, 2011 1:11 pm

Re: etv_term vector

Postby Eero Tamminen » Sat Nov 18, 2017 8:34 pm

simonsunnyboy wrote:Yes but I also want to execute additional code to dump my program's state through the Debugger console print functions, a program specific coredump facility.

Unless you provide the Hatari debugger with the ability to list my variables correctly with datatypes and readable names ;)


If you have symbols for your variables, you can list their values. I don't know how readable it's though:

Code: Select all

> symbols data
0x0003a7b4 D __app
0x0003a7b8 D _win_handle
0x0003a7bc D _win_name
0x0003a7cb D _filename
0x0003a7ec D _mode_cplx
0x0003a7f0 D _mode_trig
0x0003a7f4 D _mode_out
...
> evaluate (_filename)
  value in RAM at ($3a7cb).l = $636c6163
= %1100011011011000110000101100011 (bin), #1668047203 (dec), $636c6163 (hex)
> memdump _filename
0003A7CB: 63 6c 61 63 5f 72 73 63 2e 72 73 63 00 00 00 00   clac_rsc.rsc....
...


(Debugger shortcuts for 'evaluate' and 'memdump' are 'e' & 'm'.)

Evaluate command always reads long when asked to get value from given address (using '()'), but when using hexadecimals, that's not a problem.

You can also use it to convert values:

Code: Select all

> e $6163
= %110000101100011 (bin), #24931 (dec), $6163 (hex)
> e #24931
= %110000101100011 (bin), #24931 (dec), $6163 (hex)
> e %110000101100011
= %110000101100011 (bin), #24931 (dec), $6163 (hex)

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Sun Nov 19, 2017 9:10 am

Well how does Hatari know that I want $6163 to be a uint16_t instead? Esp. if it is part of a structure?
This evaluation thing does not help with true source level debugging. I do not wat to dig everything behind data to know how to interpret the raw memory dumps.

So I add code to provide this information.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

ThorstenOtto
Captain Atari
Captain Atari
Posts: 177
Joined: Sun Aug 03, 2014 5:54 pm

Re: etv_term vector

Postby ThorstenOtto » Mon Nov 20, 2017 11:14 am

simonsunnyboy wrote:This evaluation thing does not help with true source level debugging.


The symbols Hatari reads just don't provide such information. For this, you would need to read the debug informations, and then re-implement about 90% of gdb. Good luck with this ;)

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1563
Joined: Sun Jul 31, 2011 1:11 pm

Re: etv_term vector

Postby Eero Tamminen » Tue Nov 21, 2017 12:47 am

Well, if you're debugging your own code, you can look up the variable types from your sources, or otherwise remember them. Memdump is probably easiest way to look at the values (for 16-bit variable, just take the 4 first hex digits at given address). And if you want to know hex e.g. in decimal, use the evaluate ('e') command. It's not as convenient as source level debugger like Gdb, but at least doable.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4867
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: etv_term vector

Postby simonsunnyboy » Wed Nov 22, 2017 4:14 pm

ThorstenOtto wrote:
simonsunnyboy wrote:This evaluation thing does not help with true source level debugging.


The symbols Hatari reads just don't provide such information. For this, you would need to read the debug informations, and then re-implement about 90% of gdb. Good luck with this ;)


No problem, it is just a matter of adding some stubs to output data, basically printf to Hatari console instread of Atari side output device.

And yes, it is only done because there is no gdb for debugging TOS applications outside of an Atari environment, e.q. I atm treat Hatari as an embedded target without proper in-circuit debugging abilities.

But I also had great success, it just worked and I can even decode the proc_lives etc information from TOS exceptions:

I provoked an uneven address acces here:

Code: Select all

Address Error at address $50001, PC=$d4b4 addr_e3=d4b4 op_e3=3010

   _*
  | 
 ###
#####
 ###
----    EXCEPTION TRIGGERED    ----------------------------------------------

----   COREDUMP   -----------------------------------------------------------

 saved CPU state:
   D0: 00050001    D1: 00022079    D2: 00000000    D3: 00000000
   D4: 00000000    D5: 00000000    D6: 00000000    D7: 00000001
   A0: 00050001    A1: 00000006    A2: 003F8000    A3: 00000000
   A4: 00021F56    A5: 00000000    A6: 003F7FC6    A7: 0000D084
  uPC: 03E010E8   USP: 0000D0C0
  stack values: 3015 0005 0001 3010 2300 0000

----    DEBUGGER ENTRY    ---------------------------------------------------

CPU=$11ed8, VBL=622, FrameCycles=113716, HBL=222, LineCycles=52, DSP=N/A
$00011ed8 : 7301                               DC.W      $7301
>


I yet have to decode the number of bombs reported in the user PC value in string form....
my coredump misses output of program side information but this working from my asserts in other places.

I will make my debugging environment available on GitHub in the upcoming days.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 2 guests