Omnimaga > Ndless

Standalone relocator - Ndless-Elfloader alternative

(1/4) > >>

tangrs:
As I was using Ndless-Elfloader for one of my projects, I realized a problem.

I spent more time working out problems in the ELF loader than actually working on my problem. The ELF loader was clunky and wouldn't work on the newer OS's and it was a huge problem to maintain. That aside, prototyping a program to work using it just took way too long.

I started developing a new, lighter loader similar to Ndless's binary loader to use in my projects. It's in it's early stages right now and probably useless to most people but I have included the source in case any developers are interested in using it.

Read up the README for more information, advantages and disadvantages.

Source code

Lionel Debroux:
This yields transparent relocation support, and as such, for standalone programs, it should be quite nice :)

Among others, the approach of making programs relocate themselves was used on TI-68k calcs, as part of platform-specific startup code, for relocation formats smarter than the one supported by the OS. It works, but as you mention on the README of this new relocator, it requires custom tools...
A bit of custom tooling is not evil, and we can work with it on the long term; but when everything is platform-specific, it becomes hard to maintain in the long term. I speak from hands-on experience: I maintain GCC4TI, which has inherited from the unmaintained TIGCC a heavily patched GCC, a heavily patched binutils, a platform-specific front-end, a platform-specific linker with lots of non-portable features, etc. Obviously, most of these platform-specific changes were made for technical reasons (including reverting functionality-reducing changes in upstream GCC, many programs depended on the functionality of older GCC versions), but it hurts maintenance.


FWIW, I had started to look at porting a bFLT loader to the Nspire platform: http://ourl.ca/14975/284471 . bFLT is simple, can easily be converted from ELF, and does the job we need, AFAICT. It can handle dynamic libraries, too.
But as I mentioned in that topic, I can't handle the port alone :)

ExtendeD:
Very good job tangrs :)

I did agree with Lionel, but:
- A full-featured relocator becomes essential when using or porting existing code (for instance http://ourl.ca/14975/294135 ), we can't wait any longer.
- There's a rather high-level of turnover in the TI-Nspire developer community, so any wide-used tool must be Open Source and maintainable. Looking at Ndless-standalone-relocator's code, the ELF-part might be a bit tricky, but the relocator is rather lightweight.

tangrs, how stable is the relocator? What remains to be integrated?

[edit]
One thing I would like to be improved: the relocator currently replaces Ndless's crt0.S. Which means any startup feature non-related to relocation (such as __crt0_savedsp's initialization) will be lost when switching to ndless-standalone-relocator. What could be done to keep Ndless's crt0.S, and use startup.S as the program entry point?

Looking closer: is crt0.s actually kept, and startup.S added before it?

[edit2]
I'm trying to use it on my Windows computer, but I'm always getting the error:
makeself.exe: Unable to parse ELF file "testlibm.elf".
I'm using libelf v0.8.13 and GNU v2.21. How can we diagnose this?

Lionel Debroux:
The bFLT loader in Linux and QEMU, and the ELF -> bFLT converters, are full-featured, open source, standard and maintainable, and explicitly support dynamic, shared libraries :)
But they're not adapted for the Nspire yet, indeed, which is a significant drawback compared to ndless-standalone-relocator...

BTW, if the loader code is to remain in the program itself (which may prove suboptimal for dynamic libraries ?), maybe parts of it could be handled through "constructor" and "destructor" attributes ?

ExtendeD:

--- Quote from: Lionel Debroux on March 31, 2012, 04:13:25 am ---The bFLT loader in Linux and QEMU, and the ELF -> bFLT converters, are full-featured, open source, standard and maintainable, and explicitly support dynamic, shared libraries :)
--- End quote ---

But if several TI-Nspire specific patches need to be a applied, the maintenance burden won't be lighter than a lightweight relocator written from scratch.
And I'm not sure these currently a real need for dynamic libraries support.

Navigation

[0] Message Index

[#] Next page