Re: [hatari-devel] Diassembly output

[ Thread Index | Date Index | More Archives ]

BTW I noticed a related, but less worrisome problem. Placing CNOP directives in the assembly generates 0's instead of NOPs, and this causes disassembly to decide a 2-word instruction (ori.b #0,d0), stealing 1 word of the next instruction. This causes desync for several instructions and messes up the view.

Can't blame Hatari for this really - it's a problem with CNOP not producing nops (or configurable data).

However it seems related, so it might offer a clue :-)


On 25 January 2014 10:34, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:
Hi, this probably isn't helpful - but generally disassemblers use heuristics to figure out what is data and what is code. When they hit a meaningless instruction, they may switch to data, and continue until a label, something it already executed - or something else it figures is code again. It can often go wrong esp. if context is not used to disambiguate.

I suppose it could switch to data if it's trying to execute in 68000 mode, but it sees a 68030 opcode after a label etc. Or other random data or unknown instruction as the first op in a sequence under the pc.

Most importantly - I can imagine it having difficulty deciding when/how to switch back to code, without any labels loaded as 'TEXT' in the stream at all.

However if you've never seen it disassemble code (?) I'd probably make a new install of Hatari and a new fresh project and do some tests with that, in case you have some local configuration or other problem which is persisting in that project. I'd also look at labels vs no labels cases using simple code samples which are 68k only and begin with trivial instructions, with and without a starting label.

Sorry I couldn't be more helpful  :-)


On 25 January 2014 01:02, Miro Kropáček <miro.kropacek@xxxxxxxxx> wrote:
If you just start hatari with the binary and invoke debugger
when that binary is loaded by GEMDOS, can it at that point
disassemble this part of code?
I'm too tired now to try but I'd say the same -- I remember having this problem before (I didn't know how to load symbols but followed the Hatari manual about setting a breakpoint after GEMDOS loads the binary) and I saw those 'dc.w' statements, too.

I.e. does the disassembler corrupt it's internal state during
usage and stop showing correctly instructions it has earlier
shown right, or does it go wrong right at the beginning?
Since I have never seen it show correctly, I'd assume the latter ;) For you it works OK? I can send you the disk image (a few KBs) if you want.
[1] However, M68K PRM says that False and True conditions are NOT
    applicable to Bcc instructions?
BT = BRA, not sure about BF, whether it's allowed but DBF definitely is.
Does it matter from where you start disassembling, for whether
it gets into sync with instructions?
As I'm saying, I haven't seen it working correctly yet ;) I can press AltGr+Pause even during the TOS boot and it's still dc.w all the time.

MiKRO / Mystic Bytes

Mail converted by MHonArc 2.6.19+