Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Apr 1998 23:34:01 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        Michael Hancock <michaelh@cet.co.jp>, current@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/netinet ip_fw.c 
Message-ID:  <199804241534.XAA15328@spinner.netplex.com.au>
In-Reply-To: Your message of "Fri, 24 Apr 1998 11:15:15 -0400." <199804241515.LAA09494@khavrinen.lcs.mit.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote:
> <<On Fri, 24 Apr 1998 17:00:02 +0900 (JST), Michael Hancock <michaelh@cet.co.
    jp> said:
> 
> > On Fri, 24 Apr 1998, Terry Lambert wrote:
> >> That is, "ps" operates on system dumps as well as running systems.
> 
> We have already determined that this mode of operation will not be
> supported in the future (right, dg?).  If you want to debug a kernel
> dump, use the debugger.

IMHO, this is fine as long as gdb gets a 'ps' command.

What I'd love to see is a cross between gdb and the SVR4 crash(1M) command. 
That would be a seriously powerful combination.

root@gecko[5:19pm]~peter/src/startppp-116# crash
dumpfile = /dev/mem, namelist = /stand/unix, outfile = stdout
> ?
as             file           mount (vfs)    runq           vcproc         
async          findaddr       nm             resource       tty            
b (buffer)     findslot       od             rtdptbl        u (user)       
base           fs (vfssw)     p (proc)       rtproc         user           
buf (bufhdr)   gdp            page           s (stack)      ui (uinode)    
buffer         help           pcb            search         uinode         
bufhdr         hrt            prnode         size           v (var)        
c (callout)    i (inode)      plock          sndd           var            
callout        inode          proc           snode          vfs            
class          kfp            q (quit)       srmount        vfssw          
dbfree         kmastat        ptbl           stack          vnode          
dblock         l (lck)        pty            stat           vtop           
defproc        lck            qrun           stream         ldt            
dis            linkblk        queue          strstat        idt            
dispq          m (vfs)        quit           t (trace)      gdt            
ds             map            rcvd           trace          panic          
evactive       mbfree         rd (od)        ts             test           
evmm           mblock         rduser         tsdptbl        ?              
f (file)       mode           redirect       tsproc         !cmd           

> proc
PROC TABLE SIZE = 1024
SLOT ST  PID  PPID  PGID   SID   UID PRI CPU   EVENT     NAME        FLAGS
   0 s     0     0     0     0     0  99   0 d01ad31e sched          load sys lock nwak
   1 s     1     0     0     0     0  65   0 e0000000 init           load
   2 s     2     0     0     0     0  98   0 d10d6400 pageout        load sys lock nwak
   3 s     3     0     0     0     0  79   0 d00367e0 fsflush        load sys lock nwak
   4 s     4     0     0     0     0  74   0 d01ed530 kmdaemon       load sys lock nwak
   5 s   411   405   405   405     0  65   0 e0000000 ttymon         load jctl
   6 s   288     1   288   288     0  76   0 d12d4700 sshd           load
   7 s   159     1   159   159     0  65   0 e0000000 slink          load
   8 s   132     1   132   132     0  65   0 e0000000 update         load
   9 s   238     1   238   238     0  78   0 d01ec0cc rpcbind        load nowait
  10 s   184     1   184   184     0  78   0 d01ec0cc syslogd        load
[..]
> user
PER PROCESS USER AREA FOR PROCESS 70
PROCESS MISC:
        command: crash, psargs: crash 
        proc slot: 70   start: Fri Apr 24 23:20:21 1998
        mem: ba, type: exec
proc/text lock: none
        vnode of current directory: d11314c8
OPEN FILES AND POFILE FLAGS:

        [0]: F 0xd1312d40, 0            [1]: F 0xd1312d40, 0    
        [2]: F 0xd1312d40, 0            [3]: F 0xd1385280, 0    
FILE I/O:
        u_base:  8056ba5, file offset: 0, bytes: 0,
        segment: data, cmask: 0022
RESOURCE LIMITS:
        cpu time: unlimited/unlimited
        file size: 1073741824/1073741824
        swap size: unlimited/unlimited
        stack size: unlimited/unlimited
        coredump size: 1048576/16777216
        file descriptors: 64/1024
        address space: unlimited/unlimited
        file mode(s): write
SIGNAL DISPOSITION:
           1:  default   2: 8060408    3:  default   4:  default
           5:  default   6:  default   7:  default   8:  default
           9:  default  10:  default  11:  default  12:  default
          13:  default  14:  default  15:  default  16:  default
          17:  default  18:  default  19:  default  20:  default
          21:  default  22:  default  23:  default  24:  default
          25:  default  26:  default  27:  default  28:  default
          29:  default  30:  default  31:  default  32:  default
> callout
FUNCTION        ARGUMENT    TIME     ID
tcp_turbotimo   00000000  408444558  285111977
polltime        d135e200  408444560  285111979
polltime        d12d8c00  408444588  285111894
tcp_fasttimo    00000000  408444567  285111970
ts_update       00000000  408444572  285111880
scsi_timer      00000000  408448795  285110704
polltime        d1375e00  408444676  285111886
schedpaging     00000000  408444576  285111973
tcp_slowtimo    00000000  408444569  285111949
polltime        d1397e00  408446784  285109269
arptimer        00000000  408447372  285109661
polltime        d138cc00  408473145  285110982
polltime        d1263400  408449628  285111303
strgiveback     00000000  408448795  285110703
polltime        d12f9000  408447488  285111893
polltime        d126f200  408445306  285111941
tcp_slowtimo    00000000  408444619  285111996
ts_update       00000000  408444673  285112002
str2time        d136cc00  408442740  285109568
arptimer        00000000  408435370  285101156
str2time        d1367400  408315725  285018569
[..]

> strstat
ITEM                   ALLOC   IN USE    FREE         TOTAL     MAX    FAIL
streams                  184      184       0       5425408     243       0
queues                   998      998       0      13956470    1216       0
message blocks           482      138     344     180741104    1281       0
data blocks              436      138     298     146409935     692       0
link blocks               24       24       0            24      24       0
stream events             28        9      19         46668      28       0

Count of scheduled queues:   0

> t 13
STACK TRACE FOR PROCESS 13:
~resume(D11591B8 D01EC150 1E).......................(ebp:e0000ccc) ret:d002430e
 gcc2_compiled.(D01EC150 1E 3B8).....................ebp:e0000cf0  ret:d00895f0
*osmread+0x3c(1100 440000 440000)....................ebp:e0000d0c  ret:d0020008
*gen_read+0x64(440000 E0000DC4 D1087C00).............ebp:e0000d30  ret:d010cc83
*spec_read+0x7b(D128AB04 E0000DC4 0).................ebp:e0000d64  ret:d00387f1
 rdwr(D12896C0 E0000DC4 E0000E20)....................ebp:e0000d98  ret:d003834d
 rw(E00010B0 E0000E20 1).............................ebp:e0000ddc  ret:d0038298
*read+0x10(E00010B0 E0000E20 8002C0E0)...............ebp:e0000df0  ret:d003055a
 systrap(E0000E34)...................................ebp:e0000e28  ret:d00119d8
SYSTEM CALL from 17:8000F18E (ebp:E0000E34, ss:esp: 1F:8045D2C)
   eax:       3 ebx:8002C0E0 ecx:FFFFFFCB edx:       5 efl:     206 ds:  1F
   esi: 8054F34 edi: 804F86C esp:E0000E78 ebp: 8045D58              es:  1F

(yes, this particular SVR4.0 system was compiled with gcc, but many of the 
namelist processing stuff doesn't know about gcc's symbol pollution)

Basically crash(1M) for those who've not seen it, is kinda like a 
user-mode DDB but it knows how to display just about everything in detail 
ranging from summary mode to huge detail.

What it's missing is source level debugging support, obviously because 
SVR4 doesn't come with source for mere mortals.

So, if somebody ever had huge amounts of spare time, a combination of GDB's
source debugging, a DDB/crash(1M) style interface and a decent scripting
system would be dynamite.   We could then have a reasonable chance of
putting together a sample script to do information gathering for people to
run on their crashdumps for inclusion with send-pr etc.  Add in gdb-remote 
and you've really got something worth yelling about.

> -GAWollman

Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au>   Netplex Consulting



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804241534.XAA15328>