> Kenneth Albanowski wrote:
> > It's unclear whether ELF will be useful for the uClinux project (it's
> > relatively complicated, so we're currently using a custom -- and trivial
> > binary format). In any case, it looks like we may be able to use a few
> > trick to get located code (code that does not have to be PIC, since it is
> > linked to the exact address in the target at which it will run.)
> >
> Considering the price of FLASH (compared to hard disk), it is not
> a good solution to copy every library needed in every executable
> software, mostly if you intend to run at least different tasks.
That's a separate issue. There is no particular reason that a located
library cannot be shared by multiple tasks, as long as the "data segment"
can be placed independantly from the "code segment". There are numerous
techniques available to call into a library at an arbitrary position.
> IHMO the best thing to do is to use for each library function a
> calling way which do not need modification of the code of an
> application by the loader. That is (a little bit like DOS/BIOS
> interract) using an assembly instruction to jump at a constant
> entry point, on different micro it is called software interrupt
> (ARM, 8086), trap (68000), call door (80386)...
Yes, this is certainly an option. It's not clear, at the moment, whether a
mostly user-code technique will be used (with jump-table being set up in
the "data segment"), or something merged with the kernel so that CPU "trap
doors" would be usable. (There is also the interesting question of
allowing access to these routines from kernel space. Code sharing is of
very high importance in an embedded system.)
> You still need Position Independant Data if you intend to run
> twice the same software (via virtual memory, maybe); how about
> variable defined/unsed in library - I do not know.
This is accomlished simply by using "segment registers" to offset all
data+bss, and stack accesses. (On the 68000, this is the "A5 world".)
Allowing tasks to be moved (not for paging, which isn't feasible on a
system without MMU, but for swapping entire tasks in and out of memory) is
an unexplored issue.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu