ELF Loader for Ndless - (now ready for non-dev use)

[tangrs]

The ELF loader has reached a stage where most people can use it to load basic stuff.

When you run the program, it installs a hook. After that, you can load ELF files as if you'd load a normal Ndless binary.

More instructions on how to compile the loader and how to develop applications that take advantage of it are described in the README.

You can get the source code on Github.

Happy deving!

I'd also like to thank everyone who contributed to Ndless. I did borrow some of Ndless's code for use in this loader.

Original post:

I'm not sure if it's relevant here, but I'm developing an opensource ELF loader for Ndless.

I'm writing this because the current Ndless way of loading binaries doesn't work for code that relies on static initialization of pointers.

I.e. code like this doesn't work:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9

void foo() {   //blah } int main() {   static void (*var)() = foo; //Since it's static, the address will be inserted at link time (which is 0x8000+offset on my machine)   var(); //The GOT based relocation code in Ndless currently does not update the static variable function pointer.   return 0; //Crash }

Unfortunately, there's no way to fix this because Ndless binaries are converted into a memory image before running. That means the relocation code doesn't know what to update in the .data section of the memory because it doesn't know what symbols exist and need updating and where they're located.

Loading from an ELF file works because the symbol definitions are there and the relocation code knows where to find the bits that need patching. That's why I wrote this ELF loader.

Anyway, the core code is there, just needs a lot of polishing up.

If anyone wants to help, the source code is available on Github https://github.com/tangrs/ndless-elfloader
I'm hoping eventually, it will be integrated into the program loader on Ndless.

Thanks for your time,
Apologies if this is the wrong forum to post.

[Jim Bauwens]

Interesting

I don't however know much about this subject to give a good response
But thanks for sharing

(on a side note, did you get my pm of a few day's ago?)

[tangrs]

Interesting

I don't however know much about this subject to give a good response
But thanks for sharing

(on a side note, did you get my pm of a few day's ago?)

Yeah, I did. I couldn't respond because I'm a new user and can't send messages yet or something.

[Lionel Debroux]

Interesting indeed

The flip side of the coin of the power of ELF is its complexity, and the weight of a full-featured launcher. In the past, there were discussions about using BFLT, which is a much simpler format, easily derived from ELF, and fulfills the purpose you're describing.

[tangrs]

BFLT does look interesting. I'll look into it.

Out of curiosity, why was BFLT never used?

Edit: You're right. ELF is pretty complex. Out of the week I spent on the project, 4-5 days were spent just reading and re-reading manuals and example code

[Lionel Debroux]

Out of curiosity, why was BFLT never used?

Well, I think it has been much more a matter of finding enough free time, than a matter of feasibility

[tangrs]

Out of curiosity, why was BFLT never used?

Well, I think it has been much more a matter of finding enough free time, than a matter of feasibility

Ahhh, I see. That makes sense.

[ExtendeD]

Interesting tangrs.

But integrating to Ndless an ELF loader seems to be a bit overkilled just to support static initializers.
It's true that this would be annoying for initialization of arrays, but there's a simple workaround for this with nl_relocdata().

[tangrs]

Interesting tangrs.

But integrating to Ndless an ELF loader seems to be a bit overkilled just to support static initializers.
It's true that this would be annoying for initialization of arrays, but there's a simple workaround for this with nl_relocdata().

Oh, I know for c there are workarounds easily but I'm also working on getting C++ code working on Ndless and vtables and the lot are a lot more difficult to relocate using workarounds. That was what the ELF loader was originally for haha.

Though I do agree it might be a bit of an overkill especially considering this is an embedded platform.

Thanks for the insights guys, you guys pointed out some things I overlooked

[ExtendeD]

I see. But you can probably keep your ELF loader in user space until you reach a stable C++ toolchain, I then may integrate both if you want.

[alberthrocks]

I think an ELF loader would be amazing It would allow C++ support, and (possibly) dynamic libraries! (Although I don't think dynamic libraries would be good on the Nspire - a bundled, static package is more portable - it still will be useful for some other aspects and the thought of it being possible is nice

On a somewhat related note, is the Newlib issue on the wiki still relevant? I see that we are including newlib in the API building...

[tangrs]

I see. But you can probably keep your ELF loader in user space until you reach a stable C++ toolchain, I then may integrate both if you want.

Thanks, that would be great!

I think an ELF loader would be amazing It would allow C++ support, and (possibly) dynamic libraries! (Although I don't think dynamic libraries would be good on the Nspire - a bundled, static package is more portable - it still will be useful for some other aspects and the thought of it being possible is nice

On a somewhat related note, is the Newlib issue on the wiki still relevant? I see that we are including newlib in the API building...

Haha, dynamic libraries would be pretty interesting but would get pretty damn messy

[ExtendeD]

On a somewhat related note, is the Newlib issue on the wiki still relevant? I see that we are including newlib in the API building...

Yes It's still relevant.

[ExtendeD]

tangrs, I see on your blog that you actually have a C++ build chain that works more or less. Do C++ programs now runs with your ELF loader?
What are the "required functions" not implemented by Ndless that exception handling needs?

[tangrs]

tangrs, I see on your blog that you actually have a C++ build chain that works more or less. Do C++ programs now runs with your ELF loader?
What are the "required functions" not implemented by Ndless that exception handling needs?

Yes, the ELF loader loads most C++ programs. There's still more testing to do though but it works for the basic test programs I wrote.

The C++ buildchain is really a hit and miss kind of thing. I can't remember what kind of things the C++ compiler needed to handle exceptions - I remember that the linker was complaining about missing symbols related to C++ exceptions. I'll look into what exactly is needed for exceptions though.

Edit: Probably something like this would work.