LisaList2

Advanced search  

News:

2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: 1 [2]   Go Down

Author Topic: LisaEm Debugger  (Read 657 times)

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm Debugger
« Reply #15 on: September 02, 2020, 11:30:16 am »

Just thinking outloud here, might not implement this for a while, but...

In terms of reverse engineering LOS, I think I want to add something to keep track of stack frames, and especially the parameters pushed to the stack before any LINE10, TRAP, JSR/BSR and procedure calls. I might or might not need to deal with A7/A6 stack frames, when they're used, but likely keeping track of the changes to A7 will be good enough.

The most common pattern will be that A7 will be stable for the duration of the function/procedure, except right when we're about to call something, then items will be pushed to the stack (so A7 will decrease for 2-3 opcodes in a row), then the call will happen, on the flip side of the call, items will be pulled off the stack (or accessed relative to A7 without changing it), then for the remainder of the routine, it will stay stable, and then at the end reset to what they were before the call. So this is mostly about detecting stable A7 vs rapid changes and then a trap/call and logging that. (This won't work for things like TRAP 7 where registers are used as parameters.)

Trouble is that there's a few flavors of these in the various ABIs, so will need to detect them all, and I don't know what (eventually I'll have to deal with) UniPlus/Xenix will need there, so that code will need to be flexible.

I'll also need to figure out the PID equivalent for whatever process is currently running. I can use MMU context as a proxy for this with 0 as the OS, and 1,2,3 as upto 3 tasks, but then when LOS switches past 3 concurrent processes I'll need to know which I'm looking at, so that means maintaining separate stack trace logs for each running process, so I'll need to reverse engineer whatever PID equivalent is as well.

tl;dr This will help illuminate parameters passed to these unknown routines. This will also help with the debugger effort as it will provide similar functionality to the bt (backtrace) command in gdb.
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm Debugger
« Reply #16 on: September 02, 2020, 03:11:58 pm »

Was looking over the tables and this file which is part of libGenerator has (almost) all the definitions needed to build an assembler: https://github.com/rayarachelian/lisaem/blob/master/src/lib/libGenerator/cpu68k/def68k.def

What's missing is the size of the opcode, which can be inferred from the operands, there's some other stuff in the IIB (Instruction Information Blocks) that can also be used, but I can probably write a parser for this file and then parse what the user inputs, and match it to this file to generate a single opcode based on the bit patterns there.

I suspect there's some stuff missing there, such as some special addressing modes (like the ones in "the bug") as well as cleanly handling MOVETSR/MOVEFSR which should respectively be MOVE something,SR or MOVE SR,something, but I can fill in those edge cases.

Also would need to fill in the extension words to an opcode to this based on the input addressing modes/sizes with the proper formats.

As a sanity check I'd run the output through the built in disassembler, so the user of the LisaEm debugger sees what was assembled.

While developing it, I can run the text of the disassembly produced by the disassembler for tracelogs into the assembler, and compare the opcodes produced.

That's probably the way to go with this. Shouldn't be too difficult, but ofc, won't know until I implement.

[meta: I'm mostly writing down my thoughts on how to go about implementing this for later, that way they're not lost, and when it's time to implement, I can refer to this thread.]
« Last Edit: September 02, 2020, 03:51:33 pm by rayarachelian »
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'
Pages: 1 [2]   Go Up