Sun-Spots Digest, v7n19
William LeFebvre
Sun-Spots-Request at Rice.edu
Tue Nov 22 10:11:07 AEST 1988
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 at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at 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 at 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 at 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 at 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 at ea.ecn.purdue.edu
--- or ---
ihnp4!pur-ee!mckay!Suns-at-Home-Request
To submit an article, send it to:
Suns-at-Home at ea.ecn.purdue.edu
--- or ---
ihnp4!pur-ee!mckay!Suns-at-Home
--Dwight D. McKay, Moderator of Suns-at-Home
--mckay at courageous.ecn.purdue.edu
--ihnp4!pur-ee!mckay!dwight (at home)
------------------------------
Date: Wed, 09 Nov 88 22:05:46 -0800
From: Terry Domae <domae at 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 at nrtc.northrop.com>
Northrop Research and Technology Center
213/544-5203
------------------------------
Date: Wed, 9 Nov 88 13:29:38 EST
From: kobelan%bnrmtl.UUCP at 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 at larry.mcrcim.mcgill.edu
------------------------------
Date: Wed, 9 Nov 88 18:57:16 EST
From: ileaf!io!jaguar!dbjag at 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 at 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 at bdblues.altair.fr
Alt-E-Address: ji at cs.columbia.edu
... It's all greek to me!
------------------------------
Date: Wed, 9 Nov 88 10:42:27 GMT
From: mcvax!ecn!marcel at 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 at 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 at cc.msstate.edu
bitnet: PETERS at 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 at rice.edu". --wnl ]]
------------------------------
Date: Thu, 10 Nov 88 13:49:53 +0100
From: mcvax!nikhefk!wimh at 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 at 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 at cup.portal.com
------------------------------
Date: Wed, 9 Nov 88 13:04:54 PST
From: John L. Shelton <jshelton at 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 at 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 at 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
***********************
More information about the Comp.sys.sun
mailing list