Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!elroy!spl1!ddsw1!tarkus!jcs
From: jcs@tarkus.UUCP (John C. Sucilla)
Newsgroups: comp.sys.att
Subject: Re: Unix PC ".lib" section (Was Re: UNIXpc per-process VM limit)
Keywords: unixpc coff
Message-ID: <104@tarkus.UUCP>
Date: 14 Jun 88 00:30:47 GMT
References: <3030@crash.cts.com> <365@manta.UUCP> <1002@umbc3.UMD.EDU> <369@manta.UUCP> <1006@umbc3.UMD.EDU> <179@elgar.UUCP>
Reply-To: jcs@tarkus.UUCP (John C. Sucilla)
Organization: tarkus -- Calumet City, IL.
Lines: 20

In article <179@elgar.UUCP> ford@kenobi.UUCP (Mike "Ford" Ditto) writes:
>In article <1006@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes:
>>	The .lib section is an illusion, because its always empty in loaded
>I just tried it, it's easy with Emacs.  I just renamed the .lib section
>and it still worked.  I had to delete the section (actually just change
>filehdr.f_nscns from 4 to 3) to make it fail.  Now the program gets
>"Memory fault - core dumped" just because that one byte is changed.
>So, evidently, the kernel just looks at the number of sections to
>decide whether to use the shared library or not.

This can't be entirely true because it's possible to create an optional
header which would give you yet another section and if you retained relocation
info in the output file you have still another valid section.
All you accomplished by doing this is losing the addresses that the .lib
section supplied. In fact, you can create as many sections as you want until
you hit the limit (12, I believe) in the kernel.

-- 
John "C". Sucilla,  A silicon based life form.
       {ihnp4,chinet,ddsw1}!tarkus!jcs
  You have a better idea? Now's the time..