I found the following pitfall while rebuilding Thomas Roell's X386 v1.1

Environment: gcc 1.39 and ISC v2.2

After hacking include files some I got everything to compile and work
without shared libs. When I tried to use shared libs I got the following
ld error whenever I tried to link anything with the shared libs:

ld fatal: cannot combine NOLOAD input sections with other input sections;
possibly caused by shared library address space overlap

After a few false starts I used 'dump -hv libX11_s.a' and found out
that gcc1.39 (at least the version I ported) makes .bss sections for
uninitialized global data. It seems that pcc on ISCv2.2 does not do this,
allocating room in .data instead.

Since Thomas did not have lines of the form:

/**/#address .bss 0xB0800000

in his libxxx.def files (used for building shared libs) two section entries,
one for .data and one for .bss, were being put into the shared lib.

The .data and .bss sections had the same starting address!
This was causing ld to barf as above.

The fix I made is to go through all the *.def files in .../lib/* and reorder
the .text/.data addresses, and add a .bss entry. As far as I could see, each
of these segments must start on a 4mb boundary.

This works but a simpler solution would be nice. Is there a flag in gcc 1.39
to force stuff into .data? Maybe something else I missed?
--
Grant Munsey, Mainticore, Inc. (408) 733-3838
gr...@gouche.portal.com  or  {uunet!opusys,decwrl!apple!portal}!gouche!grant

You should also mention that you used GAS instead of AS !!!!!!

GCC&GAS produce some strange things. They place tooo much into the .bss
section. And that's the real bug !!!

GOT IT !!!!! But thats not the fault of gcc, it's the fault of gas.

1. This would not function, too. I tried it, but there were other bad problems.

2. Now you should also mention, that you created a new data-section for each
   shared lib. This means at least 4kBytes additional memory requirement, plus
   some addtional memory for the region-table, and the mmu. Now consider an
   application like xterm. This one needs libX11, libXext, libXt, libXmu &
   libXaw. I.e an addtional memory-overhead of 20k (minimum !!!).
   I think this is UNACCEPTABLE !

- Thomas

--
___________________________________________________________________________ ____
E-Mail (domain):         ro...@lan.informatik.tu-muenchen.de
UUCP (if above fails):   roell@tumult.{uucp | informatik.tu-muenchen.de}
famous last words: "diskspace - the final frontier..."

In comp.unix.sysv386, gr...@gouche.UUCP (Grant Munsey) writes:

      You're *NOT* using gcc 1.39.  This is a bug in 1.38 that was fixed
in 1.39.  I know because I had the exact same problem with 1.38 and
fixed it by going to 1.39 (I looked at the source and found that 1.39
had that bug fixed).

     -- Darryl Okahata
        UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo
        Internet: darrylo%hp...@relay.hp.com

On 21 Feb 91 08:49:12 GMT, ro...@informatik.tu-muenchen.de (Thomas
Roell) said:

roell> 2. Now you should also mention, that you created a new
roell> data-section for each shared lib. This means at least 4kBytes
roell> additional memory requirement, plus some addtional memory for the
roell> region-table, and the mmu. Now consider an application like
roell> xterm. This one needs libX11, libXext, libXt, libXmu & libXaw.
roell> I.e an addtional memory-overhead of 20k (minimum !!!).  I think
roell> this is UNACCEPTABLE !

And here Thomas Roell gets blacklisted by the Imperial MITI DRAM
Service, and will never find a job with major Unix machine vendors :-).

Too bad for you, unless of course you clarify your statement and make it
obvious that you meant to say that an additional memory overhead of 20KB
is unacceptable because it is too small! :-).
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber...@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk