Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/05/88)
SUN-SPOTS DIGEST Thursday, 4 August 1988 Volume 6 : Issue 168
Today's Topics:
Re: help with gdb and dbx using FORTRAN
Re: SLIPnet and ALM-2s under SunOS 3.5
Re: Networked Pricing Strategy.
NCAR graphics
Finding out what files your programs are opening
Busted SPARC C compiler
ethernet error messages: what do they mean?
C - compiler error?
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: Tue, 26 Jul 88 13:18:43 CDT
From: texsun!radian!cutter!markh@sun.com (Mark Hebets)
Subject: Re: help with gdb and dbx using FORTRAN
I use dbx with Fortran programs regularly, and nearly all of them make use
of include files. We ran into trouble with line numbers and include files
about the time we upgraded to 3.2, and Sun gave us a workaround that
involves passing undocumented options to f77.
Since we applied the workaround, I have had no problems with dbx losing
track of line numbers. I use a script for compiling that generates an f77
command line that looks like this:
f77 -c -f68881 -g -Qoption f77pass1 -Ename.F -I. -I$INCLUDE_DIR name.F
(The $INCLUDE_DIR is an environment variable.) Our source files all use
the '#include' statement format, with '.F' filename extensions. I have
had a few problems with the "standard" include statement, mainly in that
it is not too smart about where to look for include files. I would really
like to go to it, though, because PC-NFS makes dealing with the '.F'
extensions a real pain.
Mark Hebets, Software Applications Department, Radian Corp.
PO 201088, Austin, TX 78720 (512)-454-4797
sun!texsun!radian!markh
ut-emx!juniper/
------------------------------
Date: Tue, 26 Jul 88 15:18:28 -0400
From: dsc@seismo.css.gov (David S. Comay)
Subject: Re: SLIPnet and ALM-2s under SunOS 3.5
>So, has anyone made the "minor hardware adjustment" to get this to work (I
>assume it's either cutting a trace on the ALM or substituting a "DEC
>BR"-style plug) that would be willing to divulge this information?
actually, it is much simpler than that on the alm-1 (i'm afraid we don't
have any alm-2s around so the following is probably wrong for them).
check switch sw5 ... i believe the default as delivered by sun is sw5-5
on, with the rest of the switches in the dip off, which gives you
interrupt priority 4. we run our alm-1s with interrupt priority 3 which
is set by having sw5-4 on, the others off.
dsc
------------------------------
Date: Wed, 20 Jul 88 07:52:59 PDT
From: Neil Hunt <hunt@spar.slb.com>
Subject: Re: Networked Pricing Strategy.
I like this idea. Indeed, we have already purchased some software from
Saber, which we can run on any five of our 60 or so workstations at one
time.
However, I do have a problem with the formula which you propose; that is,
the need for additional payments to software vendors when the number of
workstations changes. In particular, at a large site with upwards of 50
or 100 workstations we might see the number of workstations hooked up vary
almost on a week by week basis. There might be perhaps 20 software
packages which might be licensed in this way (languages, SPEs, writers
tools, graphics systems...). A full-time person would then be required to
do all the purchase reqs for the additional monies to be sent to all the
software vendors, not to mention the effort required by the vendors to
track the changing situation at all of their large sites.
Saber's pricing scheme has simply a higher price per network license than
per cpu license, with a standard quantity discount schdedule. There is no
number-of-workstations factor in the equation.
This is not so unreasonable; the more workstations which have access to
the software, and the more users who can try it out, the more use it is
likely to get, and the more networked copies are likely to have to be
purchased ultimately.
------------------------------
Date: Tue, 26 Jul 88 12:34:29 PDT
From: perryc@sun.com (Perry Cross)
Subject: NCAR graphics
The January 1988 edition of Catalyst has the following listing:
MINEsoft, Ltd. NCAR Graphics with MINEsoft, Lt. Enhancements
Two- and three-dimensional plotting package
MINEsoft, Ltd.
1801 Broadway
Suite 910
Denver, CO 80202-3837
USA
(303) 292-6449
TLX 981868
Peter Zwarg
Perry Cross
SMI
[[ Interesting....that address is different than the one posted by someone
else in v6n159. --wnl ]]
------------------------------
Date: Tue, 19 Jul 88 14:33:19 EDT
From: ted@braggvax.arpa
Subject: Finding out what files your programs are opening
Folks,
If anyone knows a better way, please tell me but:
You've just completed (you think) installing a complex application with a
myriad of support files. You start to bring it up -- and it dumps core or
prints out a cryptic message like: "Can't open datafile". You've done the
install on previous versions, and you know that in all probability you've
forgotten one of the dozens of files it takes, but which one? No problem,
you'll run the program under adb and breakpoint the open calls. Oops, the
binary is stripped -- you're up the creak.
Unlikely scenario? I don't know, but it used to happen to me with a certain
set of programs all the time. When we finally upgraded our sun2s from
SunOS 2.2 to SunOS 3.5, I decided that maybe I could do something about it.
(Of course, now I rarely work with those applications (and they have been
made easier to install anyway)-- oh well). Maybe there is some easy and
obvious way to monitor all the opens a stripped program does from the user
level, but I couldn't think of it, so I came up with the following scheme:
Patch the kernel open(2) and stat(2) system call code to call special
routines that do nothing but print the name of the file being accessed
and then call the routines that open and stat were going to call anyway.
This turns out to be trivial, since both open and stat call other routines
almost immediately. You don't need to keep multiple kernels, the code
only prints if a global kernel variable is nonzero; this is settable with
adb on /dev/kmem, or a short C program.
The steps for doing this are simple:
1) Add the param.c.additional file to the end of your /sys/conf/param.c
(The code doesn't belong there, but if you are a binary site, like us,
it's an easy place to make source mods). The code is conditionally
compiled on the TRAPOPEN option.
2) Config a kernel with the TRAPOPEN option.
3) Adb the kernel using patch.adb as an example (should be an exact example
for Sun2s running 3.5. If you don't understand this, you shouldn't be
doing it.
4) Boot on the new kernel.
5) If you ever want to trap opens, use the program in trapopen.c to turn
trapping on or off.
Warnings:
1) I've only been running this code for about a week, and I make
no guarantees for it. I would wait longer, but I have time to get it
together now, and I probably won't later.
2) I'm guessing about how to use pn_alloc(), pn_get() and pn_free() based on
a quick look at a source machine.
3) The code entails an extra function call for each open and stat, whether or
not trapping is enabled. I don't think this will be a significant speed
factor, given that system calls are expensive anyway.
4) All printing in the kernel is done with printf. This will slow your system
way down when trapping is enabled. Make sure you have a console window
or your screen will be written all over.
5) This patch is running on SunOS3.5. Under 4.X if I understand it correctly,
the right thing to do would be to change the open function in the C
shared runtime library instead of patching the kernel.
I hope this is useful to somebody.
Ted Nolan
ted@braggvax.arpa
[[ The shar file has been placed in the archives under "sun-source" as
"trapopen.shar". It is 9576 bytes long. It can be retrieved via
anonymous FTP from the host "titan.rice.edu" or via the archive server.
For more information about the archive server, send a mail message
containing the word "help" to the address "archive-server@rice.edu".
--wnl ]]
------------------------------
Date: Tue, 26 Jul 88 17:02:13 CDT
From: clyde@emx.utexas.edu (Head UNIX Hacquer)
Subject: Busted SPARC C compiler
The SPARC C compiler under SunOS 4.0 can generate busted floating point code.
The following C code illustrates this problem.
---------------
#include <stdio.h>
#include <math.h>
#include <assert.h>
#include <setjmp.h>
#include <strings.h>
typedef struct dict_struct *Type;
typedef struct object
{
int flags;
Type type;
int Length;
union
{
int Integer, Boolean, Font;
float Real;
Type Dictionary;
unsigned char *String;
struct name_struct *Name;
struct op_struct *Operator;
struct file_struct *File;
struct object *Array;
} u;
} Object;
enum file_type { StringFile, StreamFile };
struct file_struct
{
enum file_type file_type;
int available;
union
{
unsigned char *c_ptr;
FILE *f_ptr;
} f;
};
struct dict_entry
{
Object entry_key, entry_value;
};
struct dict_struct
{
int dict_flags, dict_size, dict_fill;
struct dict_entry *dict_body;
};
typedef struct stack
{
int stack_fill, stack_size;
Object overflow, underflow, *stack_body;
} *Stack, StackOb;
Object MakeObject ();
extern Type Real;
static Object Make (f) float f;
{
Object res;
res = MakeObject (Real);
res.u.Real = f;
return res;
}
Object RealInteger (o) Object o;
{
return Make ((float) BodyInteger (o));
}
----------------
cc -S procduces this (annotations have been added):
----------------
.proc 010
_Make:
!#PROLOGUE# 0
sethi %hi(LF342),%g1
add %g1,%lo(LF342),%g1
save %sp,%g1,%sp
!#PROLOGUE# 1
st %i0,[%fp+0x44] # Top half of float argument
st %i1,[%fp+0x48] # Bottom half of float argument
**** NOW look below - 'i1' has NEVER BEEN SET
**** so it contains 'garbage'
( unrelated code deleted )
ld [%fp+0x44],%f0 <--- Real float-pt data (single)
ld [%fp+0x48],%f1 <--- TRASH
fdtos %f0,%f1 <--- Converted to double presicion TRASH
st %f1,[%fp+-0x4] <--- Replace with lower half of TRASH
( unrelated code deleted )
.proc 010
.global _RealInteger
_RealInteger:
( unrelated code deleted )
call _BodyInteger,1
nop
st %o0,[%sp+LP344+0x20]
ld [%sp+LP344+0x20],%f0 <-- Integer loaded
fitos %f0,%f1 <-- Convert to SINGLE float
st %f1,[%sp+LP344+0x24] <-- Stash
ld [%sp+LP344+0x24],%o0 <-- Load for argument passing
***** NOTE ONLY 'o0' is used
call _Make,1
( unrelated code deleted )
-----------
'RealInteger' converts an object with an integer into an object with a
real. The acutal conversion goes right, but when the routine 'Make' is
called, the floating point argument has been bashed. See the compiler
output above to see what is going on. Due to this C compiler bug, we have
a PostScript interpreter that we CANNOT USE on our Sun-4.
Clyde Hoover Computation Center, The University of Texas at Austin
Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas
clyde@emx.utexas.edu; ...!cs.utexas.edu!ut-emx!clyde
------------------------------
Date: Tue, 26 Jul 88 14:54:52 PDT
From: pew@ew07.nas.nasa.gov
Subject: ethernet error messages: what do they mean?
Forgive me if this has already been discussed but can someone please
explain the following error messages which I have seen on a variety of
Suns running 3.[245]:
ie0: no carrier
ie0: ethernet jammed
Explanations that I have heard so far include: loose transceiver cables,
excessive ethernet traffic, and faulty ethernet controller boards. Anyone
have a definitive answer?
John Pew
NASA Ames Research Center
pew@orville.nas.nasa.gov
...!ames!orville!pew
[[ It could be any of those things. It could also be a (transient)
problem with the cable itself. Seems like Sun 2's and 3/50's are more
likely to report that message when the Ethernet is overloaded. I think
that it's not really worth worrying about unless there are other symptoms
of Ethernet troubles (such as "NFS (or nd) server not responding"). --wnl
]]
------------------------------
Date: Tue, 26 Jul 88 14:31:57 +0200
From: unido!fuhasch!schaefer@uunet.uu.net (Ludger Schaefers)
Subject: C - compiler error?
When debugging a C-program we observed that a certain assembly language
statement for the 68020-processor is interpreted in two different ways
depending on the values of the arguments of that statement. This should
not worry anybody if the C-compiler knew about this. Since the program
that causes our problem is generated by yacc we do not have many chances
to solve our problem by changing the source code.
Here is a short description of what we observed:
The yacc - generated program segment looks like this:
int yym;
.
switch (yym) {
.
<about 2000 case labels with a lot of code>
.
}
The C-compiler compiles this to the following code:
<jump to address calculation for "switch(yym)">
yyparse+0x74 : bral yyparse+0x9d4a
<code for case statements>
.
.
.
<code for address calculation>
yyparse+0x9d4a: subl #0x1,d0 (* d0 = yym *)
yyparse+0x9d50: cmpl #0x7ea,d0
yyparse+0x9d56: bhi yyparse+0xad38
yyparse+0x9d5a: movw pc@(6,d0:l:2),d0
yyparse+0x9d5e: jmp pc@(2,d0:w)
<address table for case labels>
.
.
.
The jump statement is the statement in question. For illustrating what happens
consider the following two listings of singlestepping through this code with
yym = 1 resp. yym = 858.
First let yym = 1 (an erroneous case):
pc | relative address | statement | content of d0
-----------------------------------------------------------------------
0x251c | yyparse+0x74 | bral yyparse+0x9d4a | 0x0001
0xc1f2 | yyparse+0x9d4a | subl #0x1,d0 | 0x0001
0xc1f8 | yyparse+0x9d50 | cmpl #0x7ea,d0 | 0x0000
0xc1fe | yyparse+0x9d56 | bhi yyparse+0xad38 | 0x0000
0xc202 | yyparse+0x9d5a | movw pc@(6,d0:l:2),d0| 0x0000
0xc206 | yyparse+0x9d5e | jmp pc@(2,d0:w) | 0x6318
expected jump address: (0xc208 + 0x2 + 0x6318) mod 0x10000 = 0x2522
0x12522 | sprintf+0x46 | movl a6@(8),d0 | 0x6318
As you see the jump is not to the correct address because it is
outside yyparse.
Now let yym = 858 (a correct case):
pc | relative address | statement | content of d0
--------------------------------------------------------------------------------0x251c | yyparse+0x74 | bral yyparse+0x9d4a | 0x035a
0xc1f2 | yyparse+0x9d4a | subl #0x1,d0 | 0x035a
0xc1f8 | yyparse+0x9d50 | cmpl #0x7ea,d0 | 0x0359
0xc1fe | yyparse+0x9d56 | bhi yyparse+0xad38 | 0x0359
0xc202 | yyparse+0x9d5a | movw pc@(6,d0:l:2),d0| 0x0359
0xc206 | yyparse+0x9d5e | jmp pc@(2,d0:w) | 0xa4b0
expected jump address: (0xc208 + 0x2 + 0xa4b0) mod 0x10000 = 0x66ba
0x66ba | yyparse+0x4212 | tstw 0x2e354:l | 0xa4b0
In this case the jump is to the expected address.
Series of tests have shown that the processor's address calculation is ok
if and only if d0 >= 0x8000. In our program this value is exceeded not in
all cases since the enormous length of the switch - statement.
Does anybody see any way to overcome these problems without modifying the
yacc - generated program by hand?
The behaviour of the processor seems a little bit mystic to us since no
manual (that we know about) reports about such a feature. Are there any
explanations?
PS: We are running Sun UNIX 4.2 Release 3.4 on a 3/260, 3/160, 3/75, 3/110
which all show the same behaviour.
Ludger Schaefers
Praktische Informatik I
FernUniversitaet
Postfach 940
58 Hagen
(West Germany)
(0231) 8042660
...!unido!fuhasch!schaefer
------------------------------
End of SUN-Spots Digest
***********************