[hatari-devel] Re: New GemdosParam variable in debugger (was: EmuTOS startup sequence vs. real TOS)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

I'm answering on hatari-devel as this is about Hatari
and you're on that list too.

On 05/02/2018 09:07 PM, Christian Zietz wrote:
> Eero Tamminen schrieb:
>>> Plus, as it is right now, the problem can fortunately be easily(?) 
fixed
>>> on Hatari side. Simply have your script only trigger on Pexec(0, ...).
>>> The fake process mentioned above -- not being a PRG file on disk -- 
will
>>> never be launched via Pexec(0, ...).
>>
>> It couldn't be done with Hatari debugger, but fortunately
>> I was able to add the support for fairly easily:
>> https://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/1ad799a1479e
>> https://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/a1c66666a8e6
>
> I must say I only know a very limited subset of the capabilities of the
> Hatari debugger. Couldn't it have done conditional breakpoints based on
> some value on the stack without the commits that you mentioned?

Breakpoints don't support storing calculations / parsing them &
calculating their results on run-time.  They support only simple
things like indirect addressing for fixed addresses & registers,
masking those values, counters etc.

All calculations, are done when breakpoint is given, that's why I
needed a special variable and a function for it, that calculates
the (stack+2).w value at run-time.


> To have this feature generally (not only for GEMDOS calls) would be a
> nice extension then; so one could break on functions only when they are
> called with specific arguments.

Unlike other OS traps in Hatari, GEMDOS HD emulation code for
getting the parameters checks supervisor mode and processor type
to get correct stack address.

Can somebody explain why e.g. BIOS & XBIOS trap entries don't
need to do that in Hatari code?

For getting GEMDOS paramers in debugger at the GEMDOS trap entry
point, things seem to work fine without the extra stack checks
for the "hatari-prg-args" Pexec() use-case, but I'm not sure
whether that's true for everything else.


If the parameter extraction from stack works the same way for
all traps:

* one can use the current GemdosParam variable also in breakpoinst
  for other OS calls, as long as their first argument is word sized
* that variable could be renamed e.g. to ParamWord or CallParam

(I decided to provide the first parameter as word, because
long arguments are typically pointers and normally not
something one would need to match against.)


    - Eero