Shared library issue in Interix
This is extract from Unix Tool Forum.

http://www.interopsystems.com/tools/forum/tm.aspx?m=1794&mpage=1&key=shared%2clibrary&#1794



registering shared library image-base - Apr. 15, '04, 1:27:26 AM



As many of you know Interix 3.5 ships with the several shared libraries.
The default when you are linking applications is for the shared libraries
to be used. When an image is created information from the shared libraries
is used to determine where the memory base (image base) is located.
At run time the image is loaded and they shared libraries are loaded as
well. Each shared library has information about where it should have it's
image base should be located as well. When a conflict (image base overlap)
happens you are at the mercy of the loader determining the relocation of
one or more of the shared libraries and/or the application.

When a shared library or application is linked you can specify the image
base for each. For applications linking the default is usually quite good
so there should not be a problem. For applications the default seems to be
0x400000 (yes, we only speak in hexadecimal ).

When a shared library is linked the default image base is set to 0x10000000.
If this default is accepted and an application uses more than one shared
library using the default then an image base conflict happens. This results
in relocation. This slows things down a bit at startup. It can also result
in the available memory becoming fragmented so very large memory allocations
cannot happen. It can also result in an application's image base being different
than above which might make thing even more unfavourable.

The image base for each of the shared libraries shipped with Interix 3.5 has a
specific image base set that does not conflict with any other shared library
shipped. The spacing between them is more than enough. A rough way of stating it
is that the next higher image base must account for size of the object at this
image base (no overlaps).

To this date I've released the various additional libraries without specify an
image base. To date this hasn't been a problem. As you may guess I finally found
it to be a problem. It took some time finding this out. I'm not looking to get
bit by this again nor do I wish anyone else to get bit by it.

In most circumstances the current status won't be a problem for anyone.
I ran into the problem while working on a release of OpenDX for Interix.
You can refer to http://www.opendx.org for more info on OpenDX for now.
You can do some wicked-cool 2-D and 3-D graphics with it.
Anyway, it loads many shared libraries and is itself a large image (0x731000 bytes).
I noticed my problem when an sbrk() wasn't working for more than 0x10000 bytes.
Give rlimit was indicating I had gobs of room it didn't become clear until I mapped
out everything im memory and found that this had been relocated a fair bit causing
the memory (for sbrk()) to be squeezed down to almost nothing. Once I build the
couple of /Tools shared libraries with a specific image base then things worked
fine. I still have other work to do with OpenDX but this hurtle is over.

ANYWAY! This has been a long-winded explanation about my starting a registry list
for shared library image bases. I have all of the images bases mapped out for what
ships with 3.5. That gives a "zone" that we'll leave alone for the SFU dev folks.
For the /Tools shared libraries I'm going to go through them and assign image bases.
All of this I'm going to place in a list on the ftp-site that people can read.
If you are wanting to set an image base for a shared library that you are going to
make public this file will help you pick a "conflict free zone". This way we can
all work together in harmony

To specify an image base with ld the option (not on the man page BTW) is:

    --image-base <value>

where it's best to specify <value> in hexadecimal.
For gcc to pass it along specify it as:

    -Wl,--image-base,<value>

RE: registering shared library image-base - Apr. 17, '04, 12:44:31 AM

The file in it's current state is located at ftp://ftp.interopsystems.com/pub/lib_bases
and I'll update it as I make changes to /Tools and as people let me know their info.

People are welcome to comment and add suggestions on this.



This is a follow-up to my previous message.
I've updated a number of packages that contain libraries by changing
them so that each library has an image base. I've updated the file
listing the image bases to reflect what I've set so far. Thanks to
Mark for confirming/adding to the list.

The ones done so far (with their updated version numbers) are:

glib-2.4.0.2-bin.tgz
libiconv-1.9.2.1-bin.tgz
libcrypt-1.2.1-bin.tgz
libpng-1.2.5.3-bin.tgz
jpeg-6b.3-bin.tgz
libfreetype-2.1.4.3-bin.tgz
xrender-0.8.2.3-bin.tgz
zlib-1.1.4e-bin.tgz
xft-2.1.2.4-bin.tgz
libxpm-3.4k.3-bin.tgz
tiff-3.5.7.4-bin.tg

Each of these packages contains at least one, two, three of four libraries.
This makes about half the libraries packaged "based". So sometime next week
should see this done (probably the latter half looking at my schedule).

For those wondering: OpenDX seems to be working. I need to work out
some configuration things with it before it will be released.



RE: registering shared library image-base - Apr. 20, '04, 5:55:58 PM



This looks like you're saying that "-fPIC" is not creating a procedure linkage table (PLT) or global offset table (GOT). Is this true?

Most *ix systems don't need an image base for shared objects precisely because of the presence of the above two tables. The dynamic linker (ld.so, or whatever it may be called) is supposed to take care of the situation by filling in the GOT and PLT as needed.

I'm not running into this problem (yet), but I'm definitely curious as to how this ends up "fragmenting" memory. Most ld.so implementations use mmap and end up mapping a memory region far beyond where sbrk() might go. Is 0x10000000 too close to sbrk()'s boundary? Perhaps this should be changed in the bfd/binutils glue to something higher in memory.



RE: registering shared library image-base - Apr. 20, '04, 7:36:32 PM



The port of gcc was not finished for PIC.
So using PIC will sometimes, not all times, send code into never-never
land once it's run.
Because of the way the NT loader does things you can specify the image-base.
The 0x100000000 default location is pretty low for large applications.



RE: registering shared library image-base - Apr. 21, '04, 12:04:01 AM



Hm. No PIC? That's pretty close to a showstopper. Is PIC support still being worked on, or is it now abandoned?

Further, is it possible to use the off-the-shelf binutils if it is assumed that PIC still doesn't work? The beta-snapshot "2.13.90" shipped with SFU 3.5 has some issues, and it would be nice to use 2.14.

In that case, I guess I'll try something rather off-the-wall to support shlibs in pkgsrc and libtool under Interix 3.[015] with some degree of efficiency: an image base between, say, 0x40000000 and 0x80000000, choosing a random bitset for the 0x3FFC0000 bitmask with 12 bits of randomness. That gives a N/4096 random chance of overlap occurring (where N is the number of shlibs loaded <= 4MB, more if some are > 4MB), without having to use a registry -- something useless for automated shlib building.

Off to try out this hack of a kludge of a workaround of a patch....

In addition, I plan to submit a patch to the gcc maintainers to make -fpic/-fPIC a no-op for Interix unless you say that PIC is still under development. It shouldn't be possible to have these options do something that looks useful if it's actually harmful.



RE: registering shared library image-base - Apr. 21, '04, 12:57:39 AM



> Hm. No PIC? That's pretty close to a showstopper. Is PIC support still being worked on,
> or is it now abandoned?

It stopped. The brief history is the work started when OpenNT/Interix was
by Softway Systems (Mark, Bill and I were there). After MS bought Interix
the work continued (MS hired the guy doing the gcc/ld work). That allowed
for the work to be updated to gcc 3.X. Additional work was done beyond
what was done for gcc 2.X. MS doesn't prefer people staying with a project
too long (it's their style). So he had to move on. That's when it stopped.
I think between then and the 3.5 release someone adjusted some minor things.
I asked about PIC (and some other stuff) getting done several times, but it
didn't happen.

> Further, is it possible to use the off-the-shelf binutils if it is assumed
> that PIC still doesn't work? The beta-snapshot "2.13.90" shipped with SFU
> 3.5 has some issues, and it would be nice to use 2.14.

There are changes to binutils. So you'd want to copy the changes ahead.
But I don't see this being a problem. (Time consuming, but not a problem).

> In that case, I guess I'll try something rather off-the-wall to support shlibs in pkgsrc and libtool
>under Interix 3.[015] with some degree of efficiency: an image base between, say, 0x40000000 and
>0x80000000, choosing a random bitset for the 0x3FFC0000 bitmask with 12 bits of randomness. That gives a
>N/4096 random chance of overlap occurring (where N is the number of shlibs loaded <= 4MB, more if some
>are > 4MB), without having to use a registry -- something useless for automated shlib building.

I think I'll pass on this plan.

> In addition, I plan to submit a patch to the gcc maintainers to make -fpic/-fPIC a no-op for Interix
> unless you say that PIC is still under development. It shouldn't be possible to have these options do
> something that looks useful if it's actually harmful.

I'll agree on the do-no-harm part.
A couple/several years ago there was a company (I forget the name right now; one of the
ones that does gcc work) that was tasked to get the Interix changes merged in with the
gcc mainline of code. For reasons I don't know of, it never happened. Turning pic/PIC
off for Interix in the mainline isn't going to do a lot given the other changes aren't
there. I'll see if I can dig up who was supposed to be getting the changes done.
That might be useful to "really fixing" things.



RE: registering shared library image-base - Apr. 21, '04, 1:02:59 AM



The gcc3.3 port to Interix was done probably 18-20 months ago.
There were attempts to submit the patches back to who-ever maintains gcc but I have no idea how successful that was.
I do not believe anyone is working on gcc for Interix anymore.

The source code for the gcc3.3 port to Interix is on the SFU 3.5 distribution media. (CD/sources/Interix/gnu/...)
In case you were interested :-)



RE: registering shared library image-base - Apr. 21, '04, 1:32:24 AM

quote:

ORIGINAL: Rodney

> In that case, I guess I'll try something rather off-the-wall to support shlibs in pkgsrc and libtool
>under Interix 3.[015] with some degree of efficiency: an image base between, say, 0x40000000 and
>0x80000000, choosing a random bitset for the 0x3FFC0000 bitmask with 12 bits of randomness.

I think I'll pass on this plan.

Well, I don't see much choice on my side in absence of PIC. A registry simply will not work for automated shared library building via libtool and/or pkgsrc. We're talking about quite literally thousands of shlibs under pkgsrc that I plan to get running, and maintaining an Interix-specific base address registry for them is not going to happen.
- posted by cygwinxp @ 7:14 AM