Static linking in LGPL, Upgrading LGPL libs
in [Embedded]
|
Prev: Call for Papers: The 2010 International Conference on Computer Design (CDES'10), USA, July 2010
Next: Lab-Standard 49-Port USB Hub
From: Michael Schnell on 8 Feb 2010 15:34 On 08.02.2010 21:12, David Brown wrote: > Michael Schnell wrote: > The final linking is done by the link-loader when you start a program or > load a shared library into memory, so with ucLinux's flat binaries you > don't need PIC to run software or to use shared libraries. You will need > PID if the shared library has to keep track of application-specific > data, however. 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.) > Fair enough. The Nios2 gcc port is out-of-tree, and won't support > features that Altera don't see as important, making it a little more > limited than mainline targets. But I accept your point here. > 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
From: Michael Schnell on 8 Feb 2010 15:38 On 08.02.2010 21:12, David Brown wrote: > Where PIC is important is for XIP binaries - execute in place - which > run from flash. 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
From: David Brown on 8 Feb 2010 15:49 Michael Schnell wrote: > On 08.02.2010 21:12, David Brown wrote: >> Where PIC is important is for XIP binaries - execute in place - which >> run from flash. > > 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. > 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".
From: David Brown on 8 Feb 2010 15:59 Michael Schnell wrote: > On 08.02.2010 21:12, David Brown wrote: >> Michael Schnell wrote: > >> The final linking is done by the link-loader when you start a program or >> load a shared library into memory, so with ucLinux's flat binaries you >> don't need PIC to run software or to use shared libraries. You will need >> PID if the shared library has to keep track of application-specific >> data, however. > > 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.) > 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. >> Fair enough. The Nios2 gcc port is out-of-tree, and won't support >> features that Altera don't see as important, making it a little more >> limited than mainline targets. But I accept your point here. >> > > 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.) > 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.
From: Michael Schnell on 8 Feb 2010 16:18
On 08.02.2010 21:59, David Brown wrote: > 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. > I see. rather complicated but workable. > 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. That is what I am going to do :) -Michael |