You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EF0C is in RAM, but earlier in my analysis I had some initialized data there, which contained the value 000081cc.
That RAM block is now correctly marked as "uninitialized", but I'm left with a large number of misleading refs like this.
Is there a way to undo the damage ? The obvious re-running the analysis doesn't change anything (it's probably for the best, that the analyzer is excessively careful not to delete refs , so no complaint here).
To Reproduce
load attached .bin file as mc68000, big-endian, at address 0x88000
don't analyze now
Memory Map: add another region (read-only), starting at 0x8000, initialized with that same .bin file contents
browse to b1682 and disassemble
Expected behavior
I'm not sure... Running analysis (one-shot or globally) should 'fix everything magically' ?
And disasm would look like
000b16ec 20 79 00 movea.l (DAT_0000ef0c).l,A0 = ??
00 ef 0c
000b16f2 4e 90 jsr (A0)
Screenshots
I noticed, in the 'wrong' db, if I open the Instruction Info window, the right-hand pane shows the unwanted address xref.
This discussion was converted from issue #7908 on March 25, 2025 11:15.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
The disassembler is creating a wrong cross-ref due to an early mistake:
EF0C is in RAM, but earlier in my analysis I had some initialized data there, which contained the value 000081cc.
That RAM block is now correctly marked as "uninitialized", but I'm left with a large number of misleading refs like this.
Is there a way to undo the damage ? The obvious re-running the analysis doesn't change anything (it's probably for the best, that the analyzer is excessively careful not to delete refs , so no complaint here).
To Reproduce
Expected behavior
I'm not sure... Running analysis (one-shot or globally) should 'fix everything magically' ?
And disasm would look like
Screenshots

I noticed, in the 'wrong' db, if I open the
Instruction Info
window, the right-hand pane shows the unwanted address xref.Attachments
Current state of the project:
https://filebin.net/35d94r4ip8i4v8ox/mc68_jsr.gzf
or, to start from scratch, the following .bin file must be loaded at address 0x88000 .
https://filebin.net/35d94r4ip8i4v8ox/U21_8000.bin.zip
Environment (please complete the following information):
Beta Was this translation helpful? Give feedback.
All reactions