Sun-Spots-Request@Rice.edu (William LeFebvre) (11/22/88)
SUN-SPOTS DIGEST Friday, 18 November 1988 Volume 7 : Issue 19 Today's Topics: SunsAtHome group? Suns-at-Home mailing list SUN4 / SUNOS4.0 / C Compiler Problems stty problems/features shared/static library debugging? Incremental linking in 4.0? dbxtool & fortran 1.1 in SUN-OS 4.0? Proxy ARP daemon for Suns? SIGTERM in suntool applications? RamDisk for Sun 386i? Tek 4125 emulation? psraster question Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Wed, 9 Nov 88 11:47:00 EST From: erickson@frith.egr.msu.edu (Carl B. Erickson) Subject: SunsAtHome group? Can you please tell me how to join the SunsAtHome group? Carl Erickson Mail to home: ...!frith!moose!carl Mail to school: erickson@frith.egr.msu.edu, ...!uunet!frith!erickson [[ I'm enclosing a repeat of the announcement that appeared in v6n5 way back in January. --wnl ]] ------------------------------ Date: Fri, 8 Jan 88 10:07:54 EST From: mckay@courageous.ecn.purdue.edu (Dwight D McKay) Subject: Suns-at-Home mailing list A new mailing list is forming for those of you who have a Sun Workstation at home, Suns-at-home. This mailing list grows out of the Suns at Home SIG held at the Sun User's Group conference in San Jose this past December. To Join, send a message to: Suns-at-Home-Request@ea.ecn.purdue.edu --- or --- ihnp4!pur-ee!mckay!Suns-at-Home-Request To submit an article, send it to: Suns-at-Home@ea.ecn.purdue.edu --- or --- ihnp4!pur-ee!mckay!Suns-at-Home --Dwight D. McKay, Moderator of Suns-at-Home --mckay@courageous.ecn.purdue.edu --ihnp4!pur-ee!mckay!dwight (at home) ------------------------------ Date: Wed, 09 Nov 88 22:05:46 -0800 From: Terry Domae <domae@nrtc.northrop.com> Subject: SUN4 / SUNOS4.0 / C Compiler Problems I've recently recieved SUN4/280's and SUN4/110's and had many problems with the C compiler. I was wondering if anyone had a summary of C compiler problems? Sun refuses to return calls regarding these problems, and the Sun online database is totally out of date. A quick list that i've seen the following problems: o VARARGS are not supported, except through a very strange macro package. o The following program dealing with functions returning structures simply does not work, but if you change the structures to structure pointers things seem to work: ====================================================================== struct test { int i,j,k,l;} tester (); main () { struct test help; help = tester (); } struct test tester() { printf ("Hi, the stack is all messed up now...\n"); printf ("and you should get a core dump\n"); } ====================================================================== o The following program causes a "Watchdog Reset" on SUN4/110's and dumps core on a SUN4/280. Similar to other reported bugs on sun-spots. Note if the definition of the function foo's argument is changed from ``char **argv'' to ``char *argv[]'' things work ok. ====================================================================== #include <stdio.h> #define SOMEARGS 10 main () { int i; char argv[SOMEARGS][BUFSIZ]; strcpy (argv[1], "hello there"); foo (argv); } foo (argv) char **argv; { printf ("%s\n", argv[1]); } ====================================================================== o Some basic strageness with respect to the optimizer. Sometimes i've seen code compile and core dump, then recompiling without the -O flag causes it to work (with no code changes). A more complete summary of C compiler bugs would be nice, does anyone have one? I've also noticed that standard distributed software from SUN also has problems (like the program /usr/bin/graph). If you do the following on a vax or sun3 you get output, on a sun4 it just sits there: % echo "1.0 1.0 7.0 7.0" | graph | plot I suspect a compiler problem here. Terry Domae <domae@nrtc.northrop.com> Northrop Research and Technology Center 213/544-5203 ------------------------------ Date: Wed, 9 Nov 88 13:29:38 EST From: kobelan%bnrmtl.UUCP@larry.mcrcim.mcgill.edu (Allan Kobelansky) Subject: stty problems/features I'm running SunOS 4.0 on a 3/280. To that there are 15 diskless workstations (3/60). My problem is this: I would like to use 8N1 on my incoming serial ports. Be default they are 7E1. Obviously, at least to me, this can be tested by doing a 'stty cs8 -parenb -cstopb'. A subsequent 'stty -a' reveals that the parameters are set correctly. I then return to local mode on my PC and set 8N1. This works well... Until I run a program. If I 'vi' a file, the terminal gets reset to 'cs7 parenb' when I leave vi. Needless to say this has distasteful results as I get gobbledegook on my PC. The same thing happens on my workstations. It does not make sense that I should be *forced* to use 7E1. I've RTFMs as best I could but have found nothing documenting this behaviour. I've tried the same thing with a VT100 off a 3/60 with the same results. The modem lines are attached to an ALM/2. Any help/comments would be greatly appreciated. -Allan Kobelansky bnrmtl!kobelan@larry.mcrcim.mcgill.edu ------------------------------ Date: Wed, 9 Nov 88 18:57:16 EST From: ileaf!io!jaguar!dbjag@eddie.mit.edu (David Benjamin x4050) Subject: shared/static library debugging? I've been working on SunView applications on a Sun 386i (running SunOS 4.0) and have had numerous problems with programs that crash when I dynamically load the sunview libraries, yet don't crash when I load the same libraries (libsuntool.a, libsunwindow.a, libpixrect.a) static. The crashes are usually intermittent SIGXCPU signals and occasionally "text address not found". Aside from the irritation that intermittent bugs bring, these add to the annoyance by disappearing when the easier-to-trace, static binary is used. Does anyone have experience in flushing out bugs which only occur when the Dynamic libraries are used. (Please note, these are out-of-the-can Sun libraries, not homebrew ones) Any advice appreciated. Thanks. --Dave Benjamin -- Interleaf -- ...!eddie.mit.EDU!ileaf!dbjag ------------------------------ Date: Thu, 10 Nov 88 09:20:23 EST From: John Ioannidis <ji@cs.columbia.edu> Subject: Incremental linking in 4.0? Back in the good old days, when I wanted to do incremental linking, I would use the -A option of ld. I can still do that under 4.0, provided that my main program has been statically linked. If the main program is dynamically linked, the result of an incremental loading is also a dynamically linked program WITH ITS EXTERNAL REFERENCES UNRESOLVED, even if the module loaded has external references that should be fully satisfiable by the symbol table of the main program. What happens instead is, instructions to the run-time loaded are put in the resulting executable. Consider the following example: turandot$ cat > main.c main() { foo(0, "Hello, world\n", 13); } foo(fd, b, c) int fd, c; char *b; { return write(fd, b, c); } turandot$ cc main.c -o main turandot$ nm -n main 00002020 t crt0.o 00002020 T start 00002298 t Fcrt1.o 00002298 T fsoft_used 00002298 T start_float 000022a0 T _main 000022a0 t main.o 000022cc T _foo 000024e0 T _etext 00020000 d __DYNAMIC 00020088 D _environ 000200a0 D _edata 000200a0 B _end turandot$ file main main: mc68020 demand paged dynamically linked executable not stripped Main's purpose is really to define an entry point called _foo. As can be seen from main's namelist, _foo's address is known (obviously). Now, let's write another program that invokes foo(). turandot$ cat > bar.c bar() { foo(0,"Allo, monde\n", 12); } turandot$ cc -c bar.c turandot$ nm -n bar.o 00000000 T _bar U _foo Obviously, bar.o contains just the entry point for bar() and an unresolved external reference to foo. Since _foo is defined in main (the program), incrementally linking bar.o with respect to main should just resolve the reference and be done with it. However, this does not turn out to be the case, as the following script shows: turandot$ ld -Bstatic -A main -T 40000 bar.o turandot$ file a.out a.out: mc68020 dynamically linked executable not stripped turandot$ nm -n a.out 00040000 T _bar 00040000 t bar.o 000400dc T _etext 000400e0 d __DYNAMIC 000400f0 D _edata 00040150 B _end turandot$ Adb'ing a.out shows that in fact the external reference was not resolved: _bar+0x1c: jsr 0:l Now, if we link main.c statically, and then incrementally ling bar.o wrt to the resulting executable, everything works fine: turandot$ cc -Bstatic main.c -o main turandot$ file main main: mc68020 demand paged executable not stripped turandot$ nm -n main 00000000 d __DYNAMIC 00002020 t crt0.o 00002020 T start 00002298 t Fcrt1.o 00002298 T fsoft_used 00002298 T start_float 000022a0 T _main 000022a0 t main.o 000022cc T _foo (stuff deleted) turandot$ ld -A main -T 40000 bar.o turandot$ file a.out a.out: mc68020 executable not stripped Note how we didn't even have to specify -Bstatic in the incremental ld run. Adb'ing a.out reveals that the external reference to foo was indeed handled properly: _bar+0x1c: jsr _foo:l Now, after this brief (?!) introduction, I have two questions: (1) Is this normal behavior, or did the folks at Sun overlook something? Shouldn't _foo be resolved correctly even if main is dynamically linked? Am I missing something? (2) How can I invoke the run-time loader (ld.so) from within main? Obviously, the purpose of the whole exercise is to be able to compile, link and load (in malloc'ed space) a procedure. Even if ld handled case (1) correctly, I would still not want to be able to load in procedures that make references to, say, stdio. The way to do that is to be able to invoke ld.so right after the object module has been read in, and even have extra libraries loaded as needed. If you want a copy of the routine I have for dynamically linking and loading in malloc'ed space, send me mail. The routine together with the man page is just over 200 lines, so I'd rather not include it here. #include <appropriate disclaimers> In-Real-Life: John "Heldenprogrammer" Ioannidis Organization: GIP Altair [IN2-INRIA-LRI] P-Address: Domaine de Voluceau, BP 105 / Rocquencourt 78153 Le Chesnay / France V-Address: +33 1 39635417 E-Address: ...!mcvax!inria!bdblues!ji, ji@bdblues.altair.fr Alt-E-Address: ji@cs.columbia.edu ... It's all greek to me! ------------------------------ Date: Wed, 9 Nov 88 10:42:27 GMT From: mcvax!ecn!marcel@uunet.uu.net (Marcel Bernards) Subject: dbxtool & fortran 1.1 in SUN-OS 4.0? We are currently changing SUN 3-[5,6]0's from SUN-OS 3.5 to 4.0 We discovered that , if we try to debug a fortran program ( compiled with -g option) , and set a breakpoint anywhere, dbxtool replies with : ./source/foo.f was not compiled with the -g option after setting a breakpoint in the window. The programmer assured me that he did use the -g option of f77 and the linker (true, I checked) The bug list in the manual tells that dbx doesn't handle fortran entry points very well. The point is: Is it possible to debug fortran 1.1 and set breakpoints in the source with dbxtool ?? Local UNIX & Network System administrator, Marcel Bernards | e-mail: ..!mcvax!ecn!marcel Netherlands Energy Research Foundation, ECN | Telex : 57211 REACP NL P.O. Box 1 | Fax : -31 2246 4480 1755 ZG Petten (NH), Holland. | Phone : -31 2246 4342 ------------------------------ Date: Wed, 9 Nov 88 18:20:52 CST From: peters <peters@csserver.cs.msstate.edu> Subject: Proxy ARP daemon for Suns? I am trying to find out if there is a way to make suns use proxy ARP. We have several sun networks hung off of our building backbone. To isolate nfs traffic, we have the clients hung on a subnet...and only the servers are actually connected to the backbone. We also have on our backbone several machines that won't subnet. We would like these non-subnetted machines to be able to reach the clients that aren't actually attached to the backbone. We solved this problem in other areas by using proxy ARP. Unfortunately I can't find any mention of proxy ARP in any of the sun documentation. If anyone has any pointers to proxy arp (or any other solutions to the above scenario) I'd be most greatful. Thanks Frank W. Peters Internet: peters@cc.msstate.edu bitnet: PETERS@MSSTATE.BITNET [[ The Sun-Spots archives contains a proxyarp daemon package for (I believe) just this purpose. The shar file, 30844 bytes long, is in the "sun-source" section and is called "proxyarpd.shar". The documentation says that it works under 3.4, 3.5 and 4.0. It can be retrieved via anonymous FTP from the host "titan.rice.edu" or via the archive server with the request "send sun-source proxyarpd.shar". For more information about the archive server, send a mail message containing the word "help" to the address "archive-server@rice.edu". --wnl ]] ------------------------------ Date: Thu, 10 Nov 88 13:49:53 +0100 From: mcvax!nikhefk!wimh@uunet.uu.net (Wim Heubers) Subject: SIGTERM in suntool applications? I have some problems in handling a SIGTERM signal in a suntool application. The preferred way to quit my program (as I instructed the users) is to invoke a quit command from the frame menu. Then the program will enter twice a routine (initialized by the notifiers 'notify_interpose_destroy_func'). The first pass (DESTROY_CHECKING) is a no-op and the second pass (DESTROY_CLEANUP) does some finishing actions. This all according to the SunView manuals. Another way to quit the program is issuing the 'exit suntools' command. Doing this causes a SIGTERM to be sent to all processes running in suntools. The next step was to use the poorly documented 'notify_set_destroy_func' (page 248, SunView Programmer's Guide 3.5) to be able to do the required cleaning up in case of a SIGTERM. This works fine if a SIGTERM is fired to the process, but this messes things up if the normal quit (with confirmation) command from the frame menu is used. The SIGTERM handler is called twice and the standard confirmation pup-up is not shown. I tried several scenarios, too much to explain them all here, but none of them worked. So, does anybody know the right way to handle SIGTERM in a suntool application, without disturbing the 'quit' command ? Please send me an e-mail. Normal mail: Wim Heubers NIKHEF-K (CSG) Postbus 41882 1009 DB Amsterdam The Netherlands Phone: +31 20 5922030 ------------------------------ Date: Wed, 9-Nov-88 16:56:28 PST From: portal!cup.portal.com!Ximage_-_Corporation@sun.com Subject: RamDisk for Sun 386i? Does anyone know of a PAGEABLE RamDisk for the Sun/386i? We intend to use it as a replacement for shared memory between Unix and Dos processes. Any other strategies for implementing a shared memory between Unix and Dos would also be appreciated. Contact: Jag Narasimhan XImage Corp. Campbell, CA (408)370-2666 or via E-Mail at ximage_corporation@cup.portal.com ------------------------------ Date: Wed, 9 Nov 88 13:04:54 PST From: John L. Shelton <jshelton@ads.com> Subject: Tek 4125 emulation? We're looking for software to run on a SUN color display to emulate a Tek 4125 display. Haven't found anything in the Catalyst catalog yet that matches. Any hints? =John Shelton= ------------------------------ Date: 9 Nov 88 00:36:51 GMT From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw) Subject: psraster question The man file for psraster says that you can use it to convert multiple rasterfiles to postscript in a single invocation; e.g., psraster [options] [file1 [options] [file2] ...] I tried: psraster -i -l -z 0.48 dumpregion.file \ -i -l -z 0.48 dumpregion.file \ -i -l -z 0.48 dumpregion.file > 3files.ps (The options are "i"nvert - which actually gives a 'positive' image on a postscript printer; "l"andscape orientation; and "z"oom factor - to maintain the aspect ratio of the original and magnify it by 2.) When I examined 3files.ps, except for the postscript prologue that psraster writes at the top of the file, the postscript commands and the data for the 3 translated instances of the rasterfile were identical, as one might expect. So far so good. However, when sent by "lpr" to either an Apple Laserwriter+ or a Dataproducts LZRmumble, the first page comes out OK, while the last 2 come out with a "positive" image (OK) on a black(!) page (ignoring the page edges). What gives? Thanks, Mike Khaw -- internet: mkhaw@teknowledge.arpa uucp: {uunet|sun|ucbvax|decwrl|ames|hplabs}!mkhaw%teknowledge.arpa hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303 ------------------------------ End of SUN-Spots Digest ***********************