[hatari-devel] start and break question

[Nicolas Pomarède]

Le 05/06/2011 23:21, Eero Tamminen a écrit :
> Hi,
>
> On sunnuntai 05 kesäkuu 2011, Nicolas Pomarède wrote:
>> Le 05/06/2011 16:37, Laurent Sallafranque a écrit :
>>> Would it be esay to add an option that would let me lauch a program and
>>> break at the first instruction ?
>>>
>>> I think something like "SB (start and break)".
>>>
>>> On the desktop, I launch a program by double clicking on it's icon,
>>> then it loads, then the debugger breaks at the first instruction.
>>>
>>> It would then be easy to add breakpoints, trace the source without all
>>> the "loading garbage instructions, ..."
>>>
>> It's not necessarily easy, I'm not sure there's a TOS function that is
>> called just before jumping at the start of the program.
>
> I traced TOS 1.04 GEMDOS calls on program startup:
> GEMDOS Pexec(0, ...)
> GEMDOS call 0x2F (Fgetdta)
> GEMDOS Fsfirst("C:\HEXT837.PRG", 0x17)
> GEMDOS: C:\HEXT837.PRG ->  host: /home/eero/down/st/hextracker/hext837.prg
> GEMDOS Fsnext()
> GEMDOS Pexec(5, ...)
> GEMDOS Fopen("C:\HEXT837.PRG", 0x0)
> GEMDOS: C:\HEXT837.PRG ->  host: /home/eero/down/st/hextracker/hext837.prg
> ->  FD 0 (read-only)
> GEMDOS Fread(64, 28, 0x125dc)
> GEMDOS Fread(64, 2147483647, 0x125f8)
> GEMDOS Fclose(64)
> GEMDOS call 0x30 (Sversion)
> GEMDOS call 0x4A (Mshrink)
>
>  From this you can see that no clicking the program, TOS will call Pexec(0,)
> to load and run the program.  That will in its turn:
> - check the program existence
> - get largest available memory page and set basepage on
>    beginning of that with Pexec(5,)
> - open the program binary, load it to memory and close the file
> - set up the basepage and call the program
>
> It seems that at least on TOS 1.04, the text segment address is set between
> Sversion() and Mshrink() GEMDOS calls.
>
> If I set a PC address breakpoint to the text segment start after Mshrink(),
> it's not hit, so I think it's the program's own initialization code that's
> shrinking program's memory block to what it actually needs.

Yes, that's the expected behaviour ; after starting, a program is 
supposed to call mshrink to keep only the required memory to work and to 
give back the remaining RAM to the OS (TOS 1 or 2 are not really 
multitask, but there're soms solutions (ACC programs for example) to 
allow running several programs at once, so giving back the memory is 
required).

>
>
> I think catching the first program instruction would need a new virtual
> debugger variable that tracks the OS program basepage and the text segment
> address in that.  It would be then possible to set a breakpoint on it and
> its changes.
>
> How does that sound and how should I name that variable?

What code would you use to get the basepage on any TOS version ?

(from the above example, it seems the program was loaded at address $125dc)


Note that another easy way to set a breakpoint at the start of the 
program is to first run the program, call the debugger to see where the 
program was loaded. Then restart Hatari, set the breakpoint and run the 
program again : in identical conditions, the program will always be 
loaded at the same address by the TOS, so you can use this 2 steps 
method to manually determine where's the program's start.


Nicolas