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
no space allocated for BSS section - uninitialized global variables corrupt memory #15
Comments
then it looks like this
|
Thanks for spotting this! Just shoving everything into the same segment feels like the way to go... Do you want to do a PR, or shall I just make those changes you suggest myself? |
I have just commented out the parts and was not sure if just merging .bss into .data or putting everything to .text is preferable. So if you are for putting everything into text I'll just delete commented out stuff and make a PR with everything in .text. BTW, unfortunately it does not help with producing smaller code as I mentioned in the conversation. For that only attribute helps as it probably knows the location earlier in optimization phase and can generate proper code. When linker reshuffles stuff later into same section the suboptimal code is already generated. One example, I have code like this
and when I mark those variables with attribute section .text it generates this
By default it generates this an liker script does not help with it
so every variable reference is loaded vie separate offset and pc register :-( Anyway I can delete those .data,.bss sections in linker and make a PR with everything in .text. |
I'm just wondering now, do you think there's a way to get a section that contains the pre-initialised variables with their values? I was pretty sure that for ARM we generally had one of those and then effectively did a memcpy in the startup code. If that's the case then we could ensure evrything goes into the one section, but then load the initial values in compiler.js and manually merge it in before upload? |
Sorry, I'm lost, that is the Not sure what you are aiming at but I was thinking about actually splitting data and code so that code could live in internal flash and only writable data is in ram, but that needs handling of relocations of data references and with storage in SPI flash the code inside storage file would not be executable anyway. |
Yes. I think I misunderstood the code you posted and thought it was generating instruction code to initialise that data section instead of just having the data there. It's been a while since I looked into this so I can't 100% remember what went on
Ahh ok, personally I think that's just going to end up being too painful to do nicely. For folks who are going that far, it's really not that hard just to build their own firmwares... |
... but am I right in thinking that right now if I did:
We would end up with |
The value is already there preinitialized (now in .text segment, previously in .data segment). Same location is modified in place once the code runs.
gives
it this the |
So once you load it an run, the original value in RAM is gone. It is not a problem though, it is still part of the |
Ahh, ok, perfect - thanks! So looks like all that works as expected already |
So I guess this is fixed with #16 now |
see also conversation https://forum.espruino.com/conversations/383232/
I also remember hitting this. Workaround is to initialize variable with nonzero value like
int a = -1;
below so that it goes into .data section, not .bssHere is the difference
not initialized or initialized to zero ends with:
Initialized ends with
it can be seen that the
var bin
string is longer in initialized casewoAAAA
vswoAAAD/////
One possible fix is to put everything into text segment in the linker file as we load to RAM anyway and don't support separate data vs code and relocation of data references. Or at least the
.bss
can be included into.data
.The text was updated successfully, but these errors were encountered: