-
-
Notifications
You must be signed in to change notification settings - Fork 171
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
Opt-in link-time lint warnings, e.g. when ld can be ldh, or jp can be jr #1017
Comments
I'd say that all warnings should be enabled by |
Hm, so |
As pointed out in #1114, it would be useful to allow each warning for all occurrences of a pattern, or just the first occurrence, or not warn for that pattern. ("A pattern" might be " Inline comments or pragmas to suppress warnings at particular sites would also be useful (e.g. maybe this |
Checking if a jump target is close enough to use jr when the target label exists in a different section is bound to cause all sorts of unwanted warnings as sections get shifted around by the linker. Perhaps that feature should be limited to cases where the jump target is in the same section (or section fragment, for fragmented sections). On a similar note, a warning could also be produced when performing a suspicious call or jump. For example: if code in a non-fixed ROM bank is calling a subroutine in a different non-fixed ROM bank, then it's probably a bug. Of course many of these features can be implemented using macros, but having them built-in would be pretty convenient. |
These would be useful as opt-in link-time warnings:
For every
ld
, check for and suggest usingldh
instead if possible.(This would be an improved substitute for the removed feature of
rgbasm -L
, which optimized known-constantld
toldh
.)For every
jp
, check for and suggest usingjr
instead if possible.For every control flow instruction (
call
,jp
,jr
,rst
) targeting a label in ROMX, do a lint equivalent ofassert BANK(@) == 0 || BANK(<target>) == 0 || BANK(@) == BANK(<target>)
.(
rst
always targets ROM0, but if we add support for swappable ROM0, possibly via HDFs ([Feature request/proposal] Hardware layout description files (custom mapper support) #524), then this would be multi-banked.)Do this only if PC is in a ROMX section, which also excludes
LOAD
. (In theory,BANK(@) != 0
for ROMX, but-t
maps ROMX to ROM0. The destination is then guaranteed to be in ROM0 as well, but that may not remain the case if we add some similar feature to HDFs, so a cheap stringent check forBANK(@) == 0
is good for future-proofing.)(Possibly make this a multi-level lint, where by default cross-SECTION jumps are not checked?)
The text was updated successfully, but these errors were encountered: