Building X386v1.1
Grant Munsey
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
Thomas Roell
You should also mention that you used GAS instead of AS !!!!!!
>ld fatal: cannot combine NOLOAD input sections with other input sections;
>possibly caused by shared library address space overlap
GCC&GAS produce some strange things. They place tooo much into the .bss
section. And that's the real bug !!!
>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.
GOT IT !!!!! But thats not the fault of gcc, it's the fault of gas.
>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.
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..."
Darryl Okahata
> 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.
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
Piercarlo Grandi
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....@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