daveh@marob.MASA.COM (Dave Hammond) (06/06/88)
In compiling a large program I am getting a /bin/ld error "too many segments".
The problem seemed to go away when I combined several library archives into
a single large archive, only to return later on. The problem can obviously
be fixed with the CC flag -SEG nn, however I feel that this may be a kludge
covering up a deeper-seated problem. So:
1. Is there a preffered way to load many small object files than by using
library archives (i.e. naming *each* file on the CC command line).
2. Is there some way I can tell how many segments are being used by
/bin/ld in composing my program? Does /bin/ld leave segements
partially filled (or start new segments) based upon certain conditions ?
3. The CC man page states that -SEG will take arguments from 1 to 1024.
What is the default which was exceed here ("too many segments") ?
4. Is use of the -SEG flag common in large programs which are composed
of many small object files? If not, should modularity be sacrificed in
this case?
Should more information be required, the library in question contains the
following modules:
rwsr-sr---55/50 4332 Jun 6 11:27 1988 __.SYMDEF
rw-rw-r---55/50 606 May 20 08:53 1988 emalloc.o
rw-rw-r---55/50 1567 May 20 08:53 1988 blockmem.o
rw-rw-r---55/50 814 May 20 08:53 1988 path.o
rw-rw-r---55/50 1245 Jun 6 10:49 1988 exec.o
rw-rw-r---55/50 2814 Jun 3 09:56 1988 help.o
rw-rw-r---55/50 679 May 20 08:53 1988 gmatch.o
rw-rw-r---55/50 586 Jun 6 11:26 1988 ndate.o
rw-rw-r---55/50 659 Jun 6 09:11 1988 nextarg.o
rw-rw-r---55/50 897 May 20 08:53 1988 parse.o
rw-rw-r---55/50 603 Jun 6 10:49 1988 pipecmd.o
rw-rw-r---55/50 549 Jun 3 14:12 1988 stripwhite.o
rw-rw-r---55/50 708 May 20 08:53 1988 dumpargv.o
rw-rw-r---55/50 2298 Jun 6 10:32 1988 stdmsg.o
rw-rw-r---55/50 604 Jun 6 10:50 1988 user.o
rw-rw-r---55/50 1210 Jun 6 10:27 1988 termsetup.o
rw-rw-r---55/50 1080 May 25 08:47 1988 box.o
rw-rw-r---55/50 568 May 25 08:47 1988 center.o
rw-rw-r---55/50 4042 Jun 2 14:58 1988 screen.o
rw-rw-r---55/50 2319 Jun 3 15:14 1988 dialog.o
rw-rw-r---55/50 1145 May 25 12:26 1988 sigs.o
rw-rw-r---55/50 206 May 20 08:53 1988 kbexec.o
rw-rw-r---55/50 1164 May 20 08:53 1988 kbinit.o
rw-rw-r---55/50 202 May 20 08:53 1988 kbio.o
rw-rw-r---55/50 3249 Jun 6 10:42 1988 kbget.o
rw-rw-r---55/50 1345 May 20 08:53 1988 kbtermio.o
rw-rw-r---55/50 1003 May 20 09:48 1988 kbsyskeys.o
rw-rw-r---55/50 3311 Jun 6 10:43 1988 kbmacro.o
rw-rw-r---55/50 206 May 20 08:53 1988 kbgets.o
rw-rw-r---55/50 5340 Jun 1 16:59 1988 kbed.o
rw-rw-r---55/50 490 Jun 2 13:34 1988 Shell.o
rw-rw-r---55/50 410 May 31 14:48 1988 ChDir.o
rw-rw-r---55/50 769 Jun 3 09:33 1988 Remove.o
rw-rw-r---55/50 1936 Jun 6 10:49 1988 lrmsg.o
rw-rw-r---55/50 735 Jun 3 11:21 1988 Point.o
rw-rw-r---55/50 600 Jun 3 10:10 1988 userini.o
rw-rw-r---55/50 356 Jun 3 08:19 1988 kbgetini.o
rw-rw-r---55/50 679 Jun 3 09:57 1988 Form.o
rw-rw-r---55/50 1293 Jun 6 10:51 1988 Copy.o
rw-rw-r---55/50 4273 Jun 6 10:46 1988 form.o
rw-rw-r---55/50 1702 Jun 6 10:47 1988 form0.o
rw-rw-r---55/50 2562 Jun 3 16:36 1988 form2.o
rw-rw-r---55/50 1145 Jun 1 10:34 1988 formbgnd.o
rw-rw-r---55/50 1783 Jun 1 10:34 1988 formfgnd.o
rw-rw-r---55/50 4622 Jun 6 10:47 1988 formget.o
rw-rw-r---55/50 6482 Jun 6 10:57 1988 point.o
rw-rw-r---55/50 2284 Jun 6 10:57 1988 point1.o
rw-rw-r---55/50 3810 Jun 3 15:31 1988 point2.o
rw-rw-r---55/50 1325 Jun 1 10:37 1988 pointlist.o
rw-rw-r---55/50 1546 Jun 6 10:57 1988 dirlist.o
rw-rw-r---55/50 1445 Jun 3 14:13 1988 macini.o
rw-rw-r---55/50 3784 Jun 6 10:42 1988 msource.o
rw-rw-r---55/50 2239 Jun 6 10:43 1988 menu.o
rw-rw-r---55/50 2692 Jun 3 11:02 1988 mload.o
rw-rw-r---55/50 2745 Jun 6 10:33 1988 mbase.o
rw-rw-r---55/50 2491 May 26 13:12 1988 mdisplay.o
rw-rw-r---55/50 1289 Jun 1 11:08 1988 mstack.o
rw-rw-r---55/50 2046 May 26 13:12 1988 mpasswd.o
rw-rw-r---55/50 581 May 26 13:12 1988 keywait.o
rw-rw-r---55/50 1190 Jun 6 09:21 1988 doexec.o
rw-rw-r---55/50 673 May 26 13:13 1988 realsrc.o
The CC command line which fails is:
cc -Ml -F 1500 main.o -lutools -lcurses -ltermcap
The CC command line which is successful:
cc -Ml -F 1500 -SEG 1024 main.o -lutools -lcurses -ltermcap
Dave Hammond
UUCP: ...!marob!daveh
--------------------------------zombolas@hebron.ads.com (Gene Zombolas) (06/09/88)
In article <301@intek01.UUCP> mark@.UUCP writes: >I've been using the -SEG flag for a year with no ill effects. It is a >"kludge", but it's a kludge caused by the !@$#% segmented architecture, >not any fault of yours. > >Use -SEG and don't sweat it. While porting our companies software Sun to Xenix, I to got the "too many segments" error. What I do not understand is that was on Xenix 386, a virtual machine. The problem was made worse by cc which does not understand the -SEG argument, although it was listed in the manual. To work around this, I had to call the loader directly which is very ugly. Does anyone know what is going on here? Why is the 386 loader still dealing in segments? SCO's customer support could not answer or why cc does not understand -SEG. -Gene Zombolas
barry@n0atp.UUCP (Barry S. Berg) (06/09/88)
In article <304@marob.MASA.COM> daveh@marob.UUCP (Dave Hammond) writes: > >In compiling a large program I am getting a /bin/ld error "too many segments". >The problem seemed to go away when I combined several library archives into >a single large archive, only to return later on. The problem can obviously >be fixed with the CC flag -SEG nn, however I feel that this may be a kludge ^^^^^^^ >covering up a deeper-seated problem. So: SEG is a compiler kludge created by the fact that 8086/8 80286 etc have limited (64K) segments for data/stack/code portions. Rather than implement a simulated 32 bit work space Lattice determined to create lots of little (64K) segments when they developed their C compiler. Microsoft used the Lattice compiler, until I believe it was their 3.0 release. Thus they have carried this kludge with them. > 2. Is there some way I can tell how many segments are being used by > /bin/ld in composing my program? Does /bin/ld leave segements > partially filled (or start new segments) based upon certain conditions ? Use the option to create a map file. That map will show the segments. > 3. The CC man page states that -SEG will take arguments from 1 to 1024. > What is the default which was exceed here ("too many segments") ? 128 or 256 Segments (Brain fade is getting very acute here :-) ) > 4. Is use of the -SEG flag common in large programs which are composed > of many small object files? If not, should modularity be sacrificed in > this case? That is a programmer's decision. Each case should be considered on its own merits. However, think of the person who has to maintain the code. After all it might be me, or worse yet -- you :-) ---- Barry S. Berg DOMAIN: barry@n0atp.N0ATP.MN.ORG N0ATP Packet Radio Gateway UUCP: {...}amdahl!bungia!n0atp!barry "Speech is civilization itself--it is silence which isolates." --Thomas Mann "Moderation in all things, most especially moderation." --Author as yet unknown. -- Barry S. Berg DOMAIN: barry@n0atp.N0ATP.MN.ORG N0ATP Packet Radio Gateway UUCP: {...}amdahl!bungia!n0atp!barry "Speech is civilization itself--it is silence which isolates." --Thomas Mann "Moderation in all things, most especially moderation." --Author as yet unknown.
greg@gryphon.CTS.COM (Greg Laskin) (06/12/88)
In article <12@n0atp.UUCP> barry@n0atp.UUCP (Barry S. Berg) writes: > SEG is a compiler kludge created by the fact that 8086/8 80286 etc have > limited (64K) segments for data/stack/code portions. Rather than implement > a simulated 32 bit work space Lattice determined to create lots of little > (64K) segments when they developed their C compiler. Microsoft used the > Lattice compiler, until I believe it was their 3.0 release. Thus they > have carried this kludge with them. > The limit being exceeded is the number of uniquely named segments in the set of object modules presented to the linker. The -SEG switch tells cc to give ld an -s parameter to increase the size of ld's segment table. The -SEG switch does nothing to the compiler at all. They could of used -s but that flag was already used in cc. I don't see why this is a kludge. A similar switch has been available in most of the loaders I've used over the last 20 years. -- Greg Laskin greg@gryphon.CTS.COM <any backbone site>!gryphon!greg