Omnimaga > Ndless
Ndless bFLT loader
tangrs:
This topic will be for technical discussion for the bFLT loader.
Source code and API documentation
Let me start off this discussion.
I propose that, once bFLT becomes stable enough, it be integrated into the core Ndless code and have the SDK updated to only produce bFLT executables. However it seems that if bFLT were to be integrated into Ndless, we'll need to change some parts of the Ndless SDK itself to work in it's favor. I hope we can quickly deprecate the current way of loading binaries.
First, because bFLT stores sections in the order of .text, .data, .bss, we need to update the Ndless ldscript to reflect that. Otherwise, we run into overlapping problems. More information can be found at the bottom of the README. This is the first and easiest step.
Next: Because we do all the relocating, the startup files become redundant - even a hindrance when we deal with shared libraries. The only thing the startup files should do is branch to main since the bFLT loader will handle everything else.
Also, we need some sort of way to work out the assignment of library IDs. bFLT shared libraries work by IDs. Each library is given a unique ID and it is up to the user to ensure it is unique. Unfortunately, the number of IDs are limited and only 254 are actually available for use (255 and 0 are reserved).
I'll leave it at that for now.
@edit: is there a way of implementing _syscallvar_savedlr without relying on a linker script?
@edit2: I'm also having trouble producing a bFLT executable that doesn't rely on nspire-gcc or nspire-ld. Anyone have luck with this?
I'm having trouble writing a ldscript that will force the GOT to be at the beginning of the data section. Got it.
Update:
The bFLT loader has a working SDK ready for developing and testing! You can now produce bFLT binaries without affecting your normal Ndless SDK!
alberthrocks:
This is great! :D I was thinking about porting bFLT a while ago, but lacked skills and time to do it. This will definitely advance Nspire development quite a bit! :D
Also, do you think there's a way to change that limit?
Reading this, it says that the limit is "due to the way [he] encoded library addresses...can be changed but it requires quite a bit more effort".
I think the ID system should be changed if possible... it would be kinda weird to start assigning IDs, or having some kind of system manage IDs and such. I think having some kind of Java-style naming system, like "com.alberthrocks.myawesomelibrary", would be better. (And then call this bFLT2, Nspire edition :P) Just my 2 cents. ;)
Again, great work! :D This will open the platform to C++ code, and make porting ten-fold easier! :D
EDIT: Actually, bFLT has a version of 4.0 - I'm assuming you're using that spec, right? Also, might want to call the version 5.0 instead... :P
tangrs:
--- Quote from: alberthrocks on April 02, 2012, 09:04:07 am ---This is great! :D I was thinking about porting bFLT a while ago, but lacked skills and time to do it. This will definitely advance Nspire development quite a bit! :D
Also, do you think there's a way to change that limit?
Reading this, it says that the limit is "due to the way [he] encoded library addresses...can be changed but it requires quite a bit more effort".
I think the ID system should be changed if possible... it would be kinda weird to start assigning IDs, or having some kind of system manage IDs and such. I think having some kind of Java-style naming system, like "com.alberthrocks.myawesomelibrary", would be better. (And then call this bFLT2, Nspire edition :P) Just my 2 cents. ;)
Again, great work! :D This will open the platform to C++ code, and make porting ten-fold easier! :D
--- End quote ---
There may be a way to change the ID limit but it requires modifying the linking tools and potentially breaking application support with other bFLT loaders (is this really an issue though?).
Shared libraries are implemented by having the 'ID' of the library in the high byte of the offset record in the relocations.
For example, if a offset record read 0x030000b4, it means "look for and load a library with ID of 3 and replace this offset with (the absolute address of that library image + 0xb4). That means the maximum ID number is 255 and the lowest 0 - giving us a total ID space of 256. The first and last are reserved so that only gives us 254 to work with. When you look at it this way, it becomes difficult to modify it to have more IDs because it's more of a fundamental issue.
You're right, I like the reverse domain notation too but it seems unlikely. I'm sure we can work out something though XD.
@edit: Yep, referring to version 4 XD
Jim Bauwens:
Great work tangrs!
I think this (and the other loader stuff), deserve a news here :)
ExtendeD:
Excellent! I'll test this as soon as possible.
Navigation
[0] Message Index
[#] Next page
Go to full version