24 replies to this topic

[Illishar]

No wait, wouldn't work. If you add the elf object file as a binary resource, in your project (would be the easiest), the start address would still be wrong. You'd have to do the relocating at runtime. (Still relocating seems easier than symbol mapping.) In your current loader, are you doing 'relocation' on your addresses? Eg. adding the offset or something.

[CW2]

You'd have to do the relocating at runtime.

Or use relocatable (position-independent) code.

[Illishar]

A more throughout book for the subject: http://www.iecc.com/linker/ It wonder if the netmf doesn't already have a dynamic linker/loader somewhere.

[Illishar]

Or use relocatable (position-independent) code.

Doesn't that involve using an MMU?

[Corey Kosak]

In your current loader, are you doing 'relocation' on your addresses? Eg. adding the offset or something.

Is this question directed at me? All the code I'm generating is position-independent. The instruction set makes this easy. This is one thing I like about my framework: all the work I did was really to support the "fluent compiler"; once you have your hands on a bunch of opcodes, the support you need to invoke them is trivial (like 5 lines of code or less). For self-contained code, there's no need to care about base addresses.

Having to care about addresses comes into play when your code has to call out to other code. The way I addressed this problem in my system is that, when calling your code, the interop entry point arranges to pass in, in addition to whatever user arguments are present, one additional argument which is a vector of "interesting" firmware entry points. So when code in my system needs to call out to e.g. SetPinState, it just jumps to the address found at offset 8 of this vector.

When one of my compiled routines calls another, it passes along this vector (though it may not bother if it knows that the callee makes no external calls itself). The interesting case came up when I was trying to use code generated by my system as an interrupt service handler. In this case the code is being invoked by a caller who is not under my control (the micro framework's interrupt handling routines), and so there's no way to get it to pass you this magic vector. If you are interested you can look at the comments for Fluent Interop version 1.2 if you wanted to see how I handle this.