Ah, I now do see your point. This would mean dynamic linking but not shared object-code. I did not suppose that this is possible (as other than to void the license-issue discussed there is no big practical reason to do this.)
OTOH I suppose that this Arch will get quite low interest, as now the new NIOS2 can have an MMU and the full Linux port is available (commercially supported by WindRiver, the community distribution close to usability.)
-Michael
IMHO the even more interesting way is to use a file system in DRAM and when booting load it from a (serial) flash. Here XIP is executing as fast as "normal" and loading is much faster.
-Michael
Yes, that's another use of XIP. And even though you can write to RAM, the link-loader can't start writing address patches to the file on the "disk".
Yes, you /do/ get shared object code in this way. Suppose you have a library libfoo.so that contains a function "bar". The library's header contains a record indicating the offset of the function "bar" inside its object code section. When the link-loader loads libfoo.so somewhere in memory, it can then calculate the absolute address of "bar". Suppose you then have a program "test" that calls "bar" at some point. Within the object code section of "test", the address of "bar" is simply a placeholder (typically 0), and the header of the "test" file contains a link table with a record saying "bar" and the offset of the placeholder within the object code. When the link-loader loads "test", it copies the object code section into memory. It then runs through the link table from the file's header, and patches in the absolute address of "bar" (within the in-memory shared library) into the copy of test's object code. That's why programs are loaded by a "link-loader", not just a "loader" - the final stage of linking is carried out at load time.
When you see how this process works, it's easy to see that a second program can use the same in-memory copy of the shared library in the same way.
True enough. And while the MMU adds some overhead (both in space and speed for the NIOS2), it is almost certainly worth it if you get to run full Linux rather than ucLinux.
I see. rather complicated but workable.
That is what I am going to do :)
-Michael
Yep. Updates would be done writing into the flash and be activated with the next boot.
I'll even provide a dual flash image (with CRC check) and have the boot process load a default one if the CRC fails on the current, thus upgrading via line is quite safe.
-Michael
It's not that complicated, really, and it's the way modern Linux systems work (not just ucLinux). The alternative to load-time relocation patching of some sort is to have extra layers of indirection in all shared library calls, or to use something like software interrupts.
Not really.
If there is a conflict between what's convenient for the developer and what's convenient for the user, expect the FSF to side with the user every time.
AIUI, the FSF was born from RMS' frustration with being unable to modify the programs he was using. From his perspective, software which the user cannot modify for their particular needs is substandard and should be replaced with software which can be modified.
From that perspective, the only reason to permit developers to use certain (i.e. LGPL'd) libraries in commercial applications is that at least the user can modify that part of the program. If they couldn't even do that (because the library was linked statically and couldn't be replaced), there would be no reason to permit the developer to use the library at all.
The ultimate goal is to encourage the development and use of Free Software, meaning software that anyone can modify and share. If this benefits commercial software, that's either coincidence or a means to an end, not a goal.
This isn't quite how it works for normal ELF executables on Linux. The details are architecture dependent, but on x86, calls among shared libraries and executables indirect through a PLT (procedure linkage table).
There is a .plt section containing little stub routines for every function that is dynamically resolved. The first time such a stub is called, it branches to a function which computes the reference, and patches the stub.
The executable code of shared libraries and executables is mapped shared and read-only (when not under a debugger).
Here is an example, from an actual executable:
Disassembly of section .plt: ...
08048418 : 8048418: ff 25 f0 98 04 08 jmp *0x80498f0 804841e: 68 00 00 00 00 push $0x0 8048423: e9 e0 ff ff ff jmp 8048408The address 0x80498f0 is in another section which is called .got.plt.
The contents of *80498f0 are 804841e! I.e. it just points one instruction down.
So initially, when the program calls getchar, this stub jumps through the entry in the .got.plt, which brings it right back. It pushes $0x0 on the stack ($0x0 is the offset of the function in the PLT) and calls a routine which will resolve the symbol and patch the table to go to the right location.
We can see this live:
$ gdb ./a.out [ ... GDB messages ... ] (gdb) b main Breakpoint 1 at 0x8048556 (gdb) b getchar Function "getchar" not defined. Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (getchar) pending. (gdb) r 0 Starting program: /home/kaz/a.out 0 (no debugging symbols found) (no debugging symbols found) Breakpoint 3 at 0x2adc86 Pending breakpoint "getchar" resolved
Breakpoint 1, 0x08048556 in main () (gdb) p *(void **) 0x80498f0 $1 = (void *) 0x804841e
At this point, getchar has not been called yet, and so the PLT entry still points to the next instruction in the stub. Now we hit the breakpoint in getchar:
(gdb) c Continuing.
Breakpoint 3, 0x002adc86 in getchar () from /lib/tls/libc.so.6 (gdb) p *(void **) 0x80498f0 $2 = (void *) 0x2adc80 (gdb) p getchar $3 = {} 0x2adc80
This time when we print the contents of that PLT location, it points to the actual address of getchar. The call has been lazily resolved, but still goes through the indirect jump.
l
u/
e:
Hide quoted text -
'GPL with exception clause' is interesting. True that without applying the linking exception, code linked with GPL code becomes automatically GPL. Reer -
LGPL's linking exception appears to be more customer friendly.
Thx, Karthik Balaguru
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.