[hatari-devel] start and break question
Laurent Sallafranque
laurent.sallafranque at free.fr
Sun Jun 5 23:41:40 CEST 2011
> How does that sound and how should I name that variable?
This sounds nice to me.
You may call it something like debug_startAndBreakProgram or
debug_basepagePrg, ...
(debug to know it's a debugging variable)
PS : this variable could also be used in a graphical debugger : we could
launch a program, and if the check button "break on start" is activated,
the debugger would break on the first instruction.
This would be nice, no ?
Regards
Laurent
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.
>
>
> 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?
>
> (It would be also a very handly point to load the program debug symbols
> with correct RAM offset to the Hatari debugger, for programs that don't
> load themselves to a fixed address.)
>
>
>> But another way to do this is to run your program from MonST. Monst will
>> load the .prg but it will not run it. At this point you will know
>> where's the program's start and you can enter debuger, add breakpoint,
>> go back to emulation and run the program from Monst.
>
> - Eero
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
More information about the hatari-devel
mailing list