RE: [uCsimm] Re: [UCLINUX] Fw: 32-bit PIC patches for the uCsimm !

From: Alex Perry (
Date: Thu Jan 06 2000 - 13:43:09 EST

Vadim said:
> I'll try to explain:
> suupose you have library rootine foo(), which updates
> global variable
> errno, with the code like this:
> foo()
> {
> errno = 5;
> }
> it will be compiled to simething like:
> foo:
> mov d1,5
> mov errno(a5), d1
> ret
> Now, when you link this library to the aplllication A, errno
> offset from the
> beginnig of data segment will be let's say 0x100
> and when you link the library to application B the offset
> could be 0x200...
> In any case the actual contents of the libaray .text
> segment is different, hence you can't do code sharing.....
> Regards
> Vadim

In my suggestion that was similar, I suggested that the library text
segment would be dumped onto the end of the kernel (and therefore shared).

I had assumed, without stating it, that the data segments required
by each of those libraries would be concatenated at that time, to create
a single larger segment that would be allocated at the bottom of data
When I proposed recovering all the symbols and converting the text
symbols into pointers to the kernel area, I had assumed that the data
would remain unchanged, aka continue to be pointers into the process's
data area.

Therefore, when a normal program gets linked to these shared libraries,
the references to code located in the text segment will correctly go to
the flash rom. Since the library was linked with the data segments merged,
forced to the base and then allocated in the hacked library file,
the linker will allocate the correct amount of memory at the bottom of
the program to make room for the space needed by the shared library.

There is of course the requirement that _all_ programs be recompiled
a library is moved into this kernel sharing area, in order that additional
space is reserved in that low memory. It is less important that they get
recompiled when someone is moved out again, since this will be unused

One factor is when a program uses some (but not all) the shared libraries.
The fixed space and location allocation is reported in the hacked library
so, when the program links, the linker will see a 'hole' in low memory
whenever the sharing into the kernel left room for a library that is unused.
It will presumably fill it up with any spare suitably sized data segments.

The concept is derived from a VMS trick. So, what am I missing here ... ?

This message resent by the list server

This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:33 EST