🚀 go-pugleaf

In article <16586@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>I.e., It Would Probably Be A Good Idea if ICL did this the way Sun did,
>and if ICL just picked it up from USL, It Would Probably Be A Good Idea
>if USL did this the way Sun did....

ICL's SVR4 is the SPARC reference SVR4.  Solaris 2.x is not a real SVR4
USL release; it is a USL-Sun development tree which was branched at some
arbitrary intra-version point and dragged off by Sun to make it as
divergent as they felt like.
-- 
ROGER B.A. KLORESE                                              +1 415 ALL-ARFF
rogerk@unpc.QueerNet.ORG              {ames,decwrl,pyramid}!sgiblab!unpc!rogerk
"Sometimes you wake up.  Sometimes the fall kills you.  And sometimes, when
you fall, you fly."                                                -- N. Gaiman

>>I.e., It Would Probably Be A Good Idea if ICL did this the way Sun did,
>>and if ICL just picked it up from USL, It Would Probably Be A Good Idea
>>if USL did this the way Sun did....
>
>ICL's SVR4 is the SPARC reference SVR4.  Solaris 2.x is not a real SVR4
>USL release; it is a USL-Sun development tree which was branched at some
>arbitrary intra-version point and dragged off by Sun to make it as
>divergent as they felt like.

Nevertheless, it would *STILL* probably be a good idea if ICL did this
the way Sun did, given that the way Sun did it matches what the standard
AT&T/USL SVR4 documentation I have says, and the way ICL did it doesn't
- i.e., if you include <sys/fault.h> in SunOS 5.x, you get the fault
codes defined, just as the damn "proc(4)" man page says you do, but, it
appears, you *don't* get them defined if you include <sys/fault.h> in
the ICL system.

Not to mention the fact that putting all the fault codes in a
"sys/sparc/XXX.h" file is Just Too Fucking Stupid For Words, given that
they are intended to represent faults that just about *any* machine will
have; only an idiot would arrange that, say, the fault code for
"recoverable page fault" would have different values on the x86 SVR4,
MIPS SVR4, SPARC SVR4, etc..

In article <16609@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes:
|> >>I.e., It Would Probably Be A Good Idea if ICL did this the way Sun did,
|> >>and if ICL just picked it up from USL, It Would Probably Be A Good Idea
|> >>if USL did this the way Sun did....
|> >
|> >ICL's SVR4 is the SPARC reference SVR4.  Solaris 2.x is not a real SVR4
|> >USL release; it is a USL-Sun development tree which was branched at some
|> >arbitrary intra-version point and dragged off by Sun to make it as
|> >divergent as they felt like.
|> 
|> Nevertheless, it would *STILL* probably be a good idea if ICL did this
|> the way Sun did, given that the way Sun did it matches what the standard
|> AT&T/USL SVR4 documentation I have says, and the way ICL did it doesn't
|> - i.e., if you include <sys/fault.h> in SunOS 5.x, you get the fault
|> codes defined, just as the damn "proc(4)" man page says you do, but, it
|> appears, you *don't* get them defined if you include <sys/fault.h> in
|> the ICL system.
|> 
|> Not to mention the fact that putting all the fault codes in a
|> "sys/sparc/XXX.h" file is Just Too Fucking Stupid For Words, given that
|> they are intended to represent faults that just about *any* machine will
|> have; only an idiot would arrange that, say, the fault code for
|> "recoverable page fault" would have different values on the x86 SVR4,
|> MIPS SVR4, SPARC SVR4, etc..

I've forwarded your "flames" to the developing department at ICL, lets see
what comes out. Anyhow, in the other SVR4 port ICL has (Intel machines),
<sys/fault.h> looks out to be more reasonable.


/// Markku Niku, ICL Sweden,	mniku@icl.se
PLS OBSERVE, all I write is my opinnion, it may differ from ICL policy.

In article <1993Jan22.090028.25843@cse.iitb.ernet.in> J K Jacob Kurien,
jacob@cse.iitb.ernet.in writes:
> Hi,
> 
> I'm trying to put gdb (gnu's debugger) on top of ICL's drs6000
> sparc multiprocessor. The operating system which we have sysVr4. However
> the list of hardware faults is not listed in /usr/include/sys/fault.h. 
> There is just a pointer to /usr/include/sys/sparc/trap.h which does not 
> contain the definition for the faults  
> 
>                FLTILL        illegal instruction
>                FLTPRIV       privileged instruction
>                FLTBPT        breakpoint trap
>                FLTTRACE      trace trap
>                FLTACCESS     memory access fault
>                FLTBOUNDS     memory
>                FLTIOVF       integer overflow
>                FLTIZDIV      integer zero divide
>                FLTFPE        floating-point exception
>                FLTSTACK      unrecoverable stack fault
>                FLTPAGE       recoverable page fault

Funny, I've just been trying to do the same thing. I sort of fudged this bit,
but I'll have a go with the values Guy Harris provided. My real problem came
earlier in the game, in sparc-tdep.c. Again Sun/gdb's idea of the regset.h
definitions and ICL's seem to diverge somewhat [ :-(( ].

I found almost what I needed in /usr/include/sys/sparc/regset.h, and so I
stuck this is sparc-tdep.c

#include <sys/sparc/regset.h>
#define R_nPC R_NPC
#define R_I7 I7_REGNUM
#define prgreg_t greg_t
#define pr_fr fpu_fr
#define pr_regs fpu_regs
#define pr_fsr fpu_fsr

BUT, when I try and debug anything with gdb, I find I can run it, but
backtracing the stack doesn't work at all. I suspect that I'm not pointing at
the registers properly - but I didn't really have much idea what I ought to be
doing when I set up the #define's. I *THINK* the nPC to NPC one is OK, and
maybe even the R_I7 one (but it seems to me that should be a gdb definition
anyway, and not a /usr/include one at all. Can anyone come up with some
definitive kludges to replace this mess, please?

          Thanks.          Bob Jones
--
Robert S. Jones -- Computer Systems Manager | The opinions stated above are
Queen Mary & Westfield College, London U.K. | not necessarily .. no, dammit
Vox: +44 71 975 5326   Fax: +44 71 775 3221 | ... these are the facts!! :-)