wla-dx
wla-dx copied to clipboard
vhelin
Labels put after a section with no .ORG directive gets the wrong address
When you put some code after a section, and you neglect to even put an .ORG before your code, the label addresses become desynced from where the labels actually are in the rom.
I don't really know what the correct behaviour here should be, but this is probably not it. Though I noticed this a while ago, and neglected to file a report since this is a situation which should probably be avoided in the first place...
I thought .org started at 0, and code after the .section would start at 0. However, if the .section is placed by "force" it will then overwrite the code (with warnings).
Sections affecting .orgs unfortunately isn't a new issue. I say push the .org position when a non-forced section starts and pull it at the end, and if the section is forced then keep the .org position, but for all I know that could already be what happens.
Example:
.SECTION "Init" SIZE 100 ALIGN 4 FREE RETURNORG
-> if you give that RETURNORG, WLA will return the .ORG after .ENDS to what it was when issuing .SECTION. Does this help? It could also be the default behavior, but would that break some old software written with WLA DX?
On Sat, Aug 5, 2017 at 6:48 PM, nicklausw [email protected] wrote:
Sections affecting .orgs unfortunately isn't a new issue. I say push the .org position when a non-forced section starts and pull it at the end, and if the section is forced then keep the .org position, but for all I know that could already be what happens.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vhelin/wla-dx/issues/155#issuecomment-320450971, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHtUgSJ1X1eyzvg2fBTJ_-rBh4LDX9-ks5sVI7EgaJpZM4OnMiV .
Ville, the problem is that it is silently producing behaviour that is very wrong, and a headache to debug.
Example:
.ORG 0
.SECTION "mysection"
someCode:
...
.ENDS
someCode2:
...
The problem is that the label "someCode2" will be an unreliable label. It may be put at address $0002 in the ROM, but using the label will produce value $0000... or something like that. I haven't looked into the specifics of what it's doing, all I know is that the address it produces is wrong.
So, the fix to this isn't a matter of new features... though perhaps setting what you proposed as the default would help. I'd be surprised if any existing code relied on this behaviour, because the labels are just unusable...
I think this (making .SECTIONs to do RETURNORG by default) needs to be saved to WLA v10.0 - A change that possibly breaks things. I'm happy to do this, but not to 9.12. Unless we will implement more changes that possibly break things, and relase v10.0 instead of v9.12. :)
So, it's been a while since I opened this issue, but I'm not sure we're on the same page here? The problem I was experiencing was this:
Data is placed after a section at address $2000. However, the label that points to that data resolves to value $1000.
This isn't a matter of compatibility, it's just plain incorrect behaviour, right? It can't be interpreted as anything but a bug?
Of course, it's been forever since I opened this issue, so I can't be sure if the problem is still there. I've generally just avoided leaving anything outside of sections.
What troubles me is that if SECTIONs do RETURNORG by default, then this will not work any more:
.bank 0 slot 0 .org 0
.section "S1" FORCE nop .ends
.section "S2" FORCE nop .ends
But the good thing here is that the user is told that there is no room for S2...
Hmm, I think I can make SECTIONs do RETURNORG by default right now by turning v9.12a into v10.0a. :) I think this is a major change so WLA needs a new major number. EDIT: On second thought I guess it's better to release v9.12 now and start to work on v10.0 and add this change to it right away.
Sorry, why is the solution to this to set "RETURNORG" by default? If the data is placed at the end of the section, wouldn't that be fine? We just need to fix the labels resolving to the wrong values.
I'm not saying that using RETURNORG by default is necessarily a bad thing, but the issue as described when I opened it can be fixed without doing that...
Uh, the first messages in this thread made me think that the problem was that .SECTIONs were advancing the .ORG, but now I see that labels after and outside .SECTIONs can get corrupted. My bad. :) I'll try to debug this...
Ok, I tried to make this bug appear, but failed... Anyone with a small project that could display this bug? Or has it been fixed by some commit since Jul-2017?
I'm now on a vacation abroad and kinda gotten bored so I'm revisiting these old, hanging issues. Code inside .SECTIONs advance the .ORG by default, still, but was this the original issue or something else? .ORG is just something for the following code to start from and increment it...
If this is still an issue, please let me know! I don't feel I understand this issue completely so I'm not able to fix it.
The original issue was that the label value was not what it should be, but you didn't have a way to reproduce it. Personally I'm not bothered by this any more - I just make sure everything is in sections anyway.