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

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 ?

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

Would it be easier just to write a bFLT loader from scratch? edit: From a brief look, a bFLT loader looks easy to write - I'll have a crack at it tomorrow

For the ELF loader, I did try to port libelf to the calculator at one point but gave up and ended up just writing the whole thing from scratch.

[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?

I only finished writing it today so I haven't had time to extensively test it. It does pass the unit tests though.

One thing that did require a hacky fix was for the __got_size symbol. The linker saw that symbol as an address to something and adds it to the relocation list. Of course we know it's not an address and attempting to 'fix' it will cause a lot of problems. The temporary fix I used was just to blacklist that offset but obviously, that's no long term solution.

Most likely, this will be abandoned at one point for bFLT anyway

@edit1

Yep, startup.S is simply tacked onto the executable. The memory region looks like this:

P R G \0 [ branch instruction ] [number of relocation entries ] [relocation code ] (startup.S finishes here) [array of relocations ] [ original tns file ]
@edit2
If you could send me the ELF file you're trying to link, I can take a look at it for you.

@edit2
If you could send me the ELF file you're trying to link, I can take a look at it for you.

Here it is, I'm just trying to troubleshoot this: http://ourl.ca/14975/294135

Quote

Would it be easier just to write a bFLT loader from scratch?

I don't know.

Quote

Most likely, this will be abandoned at one point for bFLT anyway

Maybe, but for this to happen, other people than ExtendeD or I need to work on the task
Neither ExtendeD nor I have enough time to move bFLT forward at the required rate.

I looked at the specifications for bFLT and it's insanely simple. It's not worth trying to port a loader. I spent a few hours today and wrote a basic bFLT loader from scratch. It's really a trivial task compared to ELF loading. Spend a little extra time on it and dynamic libraries should be easily supported too.

I put up the source code on Github (https://github.com/tangrs/ndless-bflt-loader) with a README with all the information needed to get the loader and a elf2flt toolchain working.

Please tell me if this is okay to use.

@edit: if there's a place with comprehensive documentation about the structure of bFLT files, please do tell me. Most of the 'documentation' I've read are header files and comments in code of existing implementations.

Quote

I looked at the specifications for bFLT and it's insanely simple.

Indeed, which is several of us had thought about it

Quote

It's not worth trying to port a loader. I spent a few hours today and wrote a basic bFLT loader from scratch.

Good job, as usual

Quote

It's really a trivial task compared to ELF loading. Spend a little extra time on it and dynamic libraries should be easily supported too.

And compressed files would be the icing on the cake.

Quote

I put up the source code on Github (https://github.com/tangrs/ndless-bflt-loader) with a README with all the information needed to get the loader and a elf2flt toolchain working.

Cloned and watched.
I'm sure this will get a lot of testing soon

Quote

@edit: if there's a place with comprehensive documentation about the structure of bFLT files, please do tell me. Most of the 'documentation' I've read are header files and comments in code of existing implementations.

The main source of information I know of is http://retired.beyondlogic.org/uClinux/bflt.htm .

EDIT: I created a news about the topic of loading programs at http://tiplanet.org/forum/viewtopic.php?t=8978

Thank you. I'm very honored

Good job tangrs. You may want to create a new topic for the bFLT loader and leave this for you standalone relocator.

Also I know this is going to sound newbish but what exactly do things like bFLT and relocators let you do?

There's a detailed explanation if you look in the README for the ELF loader (https://github.com/tangrs/ndless-elfloader/blob/master/README.md).

But simply speaking, not everything is adjusted correctly when you load an ordinary Ndless binary - some bits get left behind and contain incorrect values. There are Ndless functions to help solve this but they are manual methods.

By using one of these loaders, it simply patches up whatever remained automatically.

@edit: bFLT discussion now moved to http://ourl.ca/15736