-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Address Table Formatter #160
Labels
enhancement
New feature or request
Comments
Closed
fadden
added a commit
that referenced
this issue
Jul 8, 2024
The address table formatter tries to map the calculated addresses to offsets within the file. When that fails, it currently just gives up. We now try to resolve external addresses to project/platform symbols. (issue #160)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(There have been a number of requests for enhancements to the address table formatter. I'm collecting them here.)
The "Format Address Table" feature formats tables of addresses. These can come in a variety of forms, such as a list of 16-bit addresses:
8-bit software often splits the high and low bytes into parallel arrays, like this:
The purpose of the formatter is to format the bytes as symbolic operands. If the referenced address has a label, we use that. If it doesn't, a new label is generated ("Txxxx").
Tables can be 8-bit, 16-bit words, 16-bit split, 24-bit words, 24-bit split. The high byte in a 16-bit or 24-bit address can be set to a fixed value. When the table is split into low/high/bank parts, the various pieces don't have to be adjacent in memory. They do need to be the same size, however.
For jump tables, it can also mark the target addresses as code entry points. Because it's common to load the values, push them on the stack, and
RTS
, the target address may need to be adjusted by one byte.The existing implementation does not create an entity that defines the location and structure of the table. Instead, it performs a one-time bulk format of the various items as a single operation. It doesn't do anything that couldn't be done manually; it just does it faster. The output shown in the format dialog is just a preview, to make it easier to tell if the parameters are correct.
Areas for improvement:
<(MyLabel+280)
and>(MyLabel+280)
, not<MyLabel+24
and>MyLabel+1
.<(SYM+$01)
and>(SYM+$60)
rather than<(SYM+$0160)
and>(SYM+$0160)
. (A minor change can make that<(SYM+$0100)
, but the low byte reference can't be fixed so easily. We may need to add a "full value" field to the data formatter entry.)See also issue #141 (reference to relocated code).
Different Approach
Most of the requests can be satisfied with the existing format-and-forget approach. However, there may be value in switching to a mechanism that makes address tables an actual object that is re-evaluated every time the analyzer runs.
This came up here and in some other discussions. It offers two advantages:
The trouble with this approach is that, if you create an object in the project, you will want a way to edit it. Specifically, a way to override the behavior for specific entries. Sometimes tables have junk in them,
e.g. if valid inputs are the letters "abef", the table might have entries for all of a,b,c,d,e,f, with junk values for c/d since they can never be used. Without a way to flag those as junk, the disassembler might try
to chase some bad references.
Larger changes, like expanding or contracting the table, might need to be handled by deleting and regenerating the table.
We also need to figure out how to store the table and how to handle conflicts. It probably needs to be a high-level object, rather than a format descriptor, because it potentially spans a non-contiguous range of bytes. Conflict resolution is mostly a matter of deciding whether the table gets handled before the formatting associated with individual offsets. We'd want to disallow creation of overlapping address table objects, and reject overlaps found in the project file.
The text was updated successfully, but these errors were encountered: