From owner-kdb@oss.sgi.com Wed Nov 8 15:55:42 2000 Received: by oss.sgi.com id ; Wed, 8 Nov 2000 15:55:32 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:10068 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 8 Nov 2000 15:55:13 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA19708 for ; Wed, 8 Nov 2000 15:47:20 -0800 (PST) mail_from (max@kuku.melbourne.sgi.com) Received: from kuku.melbourne.sgi.com (kuku.melbourne.sgi.com [134.14.55.163]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14009 for ; Thu, 9 Nov 2000 10:52:38 +1100 Received: (from max@localhost) by kuku.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA09922; Thu, 9 Nov 2000 10:52:37 +1100 (EST) To: kdb@oss.sgi.com Subject: Source level debugging with kdb From: Max Matveev Date: 09 Nov 2000 10:52:37 +1100 Message-ID: Lines: 1154 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing Some of you may remember that Keith mentioned a possibility of having source level debugging with kdb via proxy. I finally dragged myself to writing a little Readme note about it so it can be used by somebody other then myself. Here it is. Source level debugging with kdb In order to be able to use source level debugging with kdb, we need access to some information which is not stored in the running kernel. We also need to do I/O during the debugging to get the info we need from a file. All this means that 2 machines with a serial link have to be used. Once machine, which will run the kernel we're going to debug, will be called target, the other, which will run gdb and kdb proxy (I've called it skdb for Symbolic Kernel Debugger) will be called host. There is also a possibility to use remote hosts via a terminal server which supports telnet to serial mapping. To start the debugging session one starts skdb with the appropriate kernel image, i.e $ skdb ../../linux/2.4.0-pre9-with-kdb-debug/vmlinux skdb will spawn gdb and convince it that it should talk to a proxy. Proxy will translate gdb serial protocol to kdb commands and will talk via the serial link to the target. Proxy will interrupt the target and target will be in kdb mode until it is specifically told to resume execution via 'continue' or 'detach'. By default proxy assumes that serial port 1 (aka /dev/ttyS0) at 38400 bps will be used to communicate between the host and the target. This can be changed via -l command line option. -l /dev/foo:12345 will change the device to /dev/foo and set speed at 12345 bps. To use remote terminal server -l somehost:someport is used to tell skdb to connect to host 'somehost' on the port 'someport' and talk telnet to it. Note, that if the file 'somehost' exists and it a character device, skdb will try to use serial connection. There is a possibility to execute any kdb command via a 'monitor' command from gdb, i.e gdb> mon bt will execute backtrace command in kdb and print the result back. Known limitation. At the moment skdb supports only ia32 targets (it assumes a lot of stuff about registers etc). There is no support for modules but it is planned. There is no support for memory writes but it can be added provided there is interest. Sources. All sources is in one file, attached to this message. Save it, compile it and run it. max /***********************************************************\ * Copyright (C) 2000 SGI * Released under the terms of GNU Public License v.2 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Project: GDB-KDB interface * Module: GDB remote debugging protocol * File: skdb.c * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * $Id: skdb.c,v 1.1 2000/11/08 23:42:49 max Exp max $ \***********************************************************/ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define TELOPTS #define TELCMDS #include #define SKDB_MAX_REQSIZ (16384) /* Debug flags - options should match 1 << name */ char * dopt[] = {"all", "serial", "telnet", "remote", NULL}; unsigned int debug = 0; #define SKDB_DBG_SERIAL 2 #define SKDB_DBG_TELNET 4 #define SKDB_DBG_REMOTE 8 int pfork (int, char **); char * getgdbpkt (char * inqueue, char ** pkt); int putgdbpkt (int fd, char * data); char * kdb_request (int, const char *); unsigned long * breakaddrs = NULL; int breaks = 0; int telnetmode = 0; int isRunning = 1; /* This is the order in which gdb knows x86 regs. */ static const char * regnames[] = { "eax", "ecx", "edx", "ebx", "esp", "ebp", "esi", "edi", "eip", "eflags", "cs", "ss", "ds", "es", "fs", "gs", NULL}; /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\ * Function: getgdbpkt * Find something which looks, smells and sounds like a gdb * packet (i.e, it starts with $ and ends with #XX), check * the control sum and return the pointer to the end of * the packet to the caller. Pointer to the start of the packet * is returned via the 'pkt' parameter * Parameters: * inqueue - input buffer which may contain the packet * pkt - pointer * Returns: * pointer of the last charcter in the input buffer, which is not * in the packet to be processed, on success or NULL on error. If * packet has not been found, pkt is left unmolested. \* * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ char * getgdbpkt (char * inqueue, char ** pkt) { while (*inqueue != '$' && *inqueue != '\0' ) { inqueue++; } if ( *inqueue == '\0' ) { /* No $ - no packets, skip the whole lot */ return inqueue; } else { char * start = ++inqueue; while ( *inqueue != '#' && *inqueue != '\0' ) { inqueue++; } if ( *inqueue == '\0' ) { /* We've seen the start of the packet but not the end of it */ return start; } /* Check for the obsolete sequence id and reject the packet if * there is one */ if ( (inqueue - start) > 3 && isxdigit (start[0]) && isxdigit (start[1]) && (start[2] == ':')) { return (NULL); } else { /* End of the packet - calculate checksum */ char * p = start; unsigned int chksum = 0; char s[3] = {inqueue[1], inqueue[2], '\0'}; int ctrlsum = strtol (s, NULL, 16); while ( p != inqueue ) { chksum = (chksum + *p++ ) & 0xFFU; } if ( ctrlsum != chksum ) { fprintf (stderr, "\nskdb: Bad Checksum: %d != %d\n", ctrlsum, chksum); return (NULL); } if ( pkt != NULL ) { *pkt = start; } inqueue += 3; } } return (inqueue); } /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\ * Function: putgdbpkt * Form a kosher gdb packet and send it down to gdb using * file descriptor provided * Parameters: * fd - file descriptor which gdb can be reached thru * data - pointer to the content of the packet to be sent * Returns: * number of bytes send to gdb on success or -1 on error \* * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ int putgdbpkt (int fd, char * data) { char * pkt = malloc (strlen(data)+5); if ( pkt != NULL ) { unsigned int chksum = 0; int sz = 0; pkt[sz++] = '$'; while ( *data != '\0' ) { pkt[sz++] = *data; chksum = (chksum + *data++) & 0xFFU; } sprintf (pkt+sz, "#%02X", chksum); if ( write (fd, pkt, sz+3) != sz+3 ) { extern int errno; fprintf (stderr, "putgdbpkt: write (%d, ... , %d) - %s", fd, sz+3, strerror (errno)); return (-1); } free (pkt); return (sz); } return (-1); } /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\ * Function: find_kdb_prompt * Telnetd will sent NULs for CR (see rfc1184 or * its successor), so we have to work around them * here. * Parameters: * reply - stuff we've got back from kdb * sz - how much have we got? * Returns: * Pointer to the start of the prompt on success or NULL * if there is no prompt. \* * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ char * find_kdb_prompt (char * reply, int sz ) { char * l; for ( l = reply; l < reply + sz; l += strlen (l)+1 ) { char * prompt = strstr (l, "kdb> "); if ( prompt != NULL ) { return (prompt); } } return (NULL); } /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\ * Function: kdb_request * Send kdb interrupt key, send simple request, i.e one * kdb command, wait for the result, send go and return * the result. * Parameters: * fd - file descriptor to reach kdb * req - request * Returns: * pointer to the dynamically allocated region of memory * on success or NULL on error \* * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ char * kdb_request (int fd, const char * req) { char buf[SKDB_MAX_REQSIZ]; int bc = 0, seek = 1; fd_set fds; struct timeval tv; FD_ZERO (&fds); if ( isRunning ) { write (fd, "\1", 1); /* KDB attention key */ } else { write (fd, "\n\r", 2); } /* Wait for kdb prompt */ while ( seek ) { FD_SET (fd, &fds); tv.tv_sec = 15; tv.tv_usec = 0; if ( select (fd+1, &fds, NULL, NULL, &tv) > 0 ) { int nb = read (fd, buf+bc, SKDB_MAX_REQSIZ-bc-1); if ( nb > 0 && ((bc + nb) < SKDB_MAX_REQSIZ)) { bc += nb; buf[bc+1] = '\0'; if ( find_kdb_prompt (buf, bc) != NULL ) { seek = 0; bc = 0; isRunning = 0; } } else { fputs ("\nskdb: Request is too big\n", stderr); fflush (stderr); return (NULL); } } else { fputs ("\nskdb: Timed out while trying to get kdb attention\n", stderr); fflush (stderr); return (NULL); } } /* Check if we have smth to request or if it was just an interrupt */ if ( req[0] ) { /* Send request */ write (fd, req, strlen (req)); write (fd, "\n\r", 2); /* Read reply until we find a second prompt, unless it's a 'go' - * in this case we just return */ if ( strncmp (req, "go", 2) ) { seek = 1; while ( seek ) { FD_SET (fd, &fds); tv.tv_sec = 5; tv.tv_usec = 0; if ( select (fd+1, &fds, NULL, NULL, &tv) > 0 ) { int nb = read (fd, buf+bc, SKDB_MAX_REQSIZ-bc-1); if ( nb > 0 && ((bc + nb) < SKDB_MAX_REQSIZ) ) { char * pstart; bc += nb; buf[bc+1] = '\0'; if ( (pstart = find_kdb_prompt(buf, bc)) != NULL ) { char * nl; if ( telnetmode ) { char * nul; while ((nul=memchr (buf, '\0', bc)) != NULL) { memmove (nul, nul+1, buf+bc-nul-1); bc--; } } *pstart = '\0'; if ( (nl = strrchr (buf, '\n')) != NULL ) { seek = 0; *pstart = 'k'; bc = nl - buf; *nl = '\0'; } } } else { return (NULL); } } else { return (NULL); } } } else { isRunning = 1; return (strdup ("")); } } else { return (strdup ("")); } return (strdup (buf)); } /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\ * Function: gdb_process * Process one gdb packet. One gdb packet my result to zero, * one or no requests to kdb. * Parameters: * pm - file descriptor to talk to gdb * kdb - file descriptor to talk to kdb * pkt - gdb packet sense control sum \* * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ void gdb_process (int pm, int kdb, char * pkt) { char * start = NULL, *end; if ( ((end = getgdbpkt (pkt, &start)) != NULL) && (start != NULL) ) { unsigned long bpaddr; int i; char reply[SKDB_MAX_REQSIZ] = ""; char * sep; write (pm, "+", 1); /* ACK the packet */ switch ( *start ) { case 'c': /* Continue - do nothing, just ACK the packet. The rest * will come from the kdb */ free (kdb_request (kdb, "go")); break; case 'D': /* GDB doesn't want to play no more but it still * wants a reply regardless of what is said in the * manual */ free (kdb_request (kdb, "go")); putgdbpkt (pm, "OK"); break; case 's': free (kdb_request (kdb, "ss")); putgdbpkt (pm, "S00"); break; case 'H': putgdbpkt (pm, "OK"); break; case 'm': /* Memory read */ if ( (sep = strchr (start+1, ',')) == NULL ) { strcpy (reply, "E01"); } else { char * aend; unsigned long addr = strtoul (start+1, &aend, 16); if ( aend != sep ) { strcpy (reply, "E01"); } else { int sz = atoi (sep+1); char * res; sprintf (reply, "mdr 0x%x %d", addr, sz); if ( (res = kdb_request (kdb, reply)) == NULL ) { putgdbpkt (pm, "E02"); } else { char * nl = strrchr (res, '\n'); if ( nl == NULL ) { putgdbpkt (pm, "E02"); } else { int i; for (i = strlen (nl)-1; i>0; i-- ) { if ( ! isxdigit (nl[i]) ) { break; } } if ( i ) { /* Wrong address */ putgdbpkt (pm, "E03"); } else { putgdbpkt (pm, nl+1); } } free (res); } } } break; case 'P': /* Set register */ if ( (sep = strchr (start+1, '=')) == NULL ) { strcpy (reply, "E01"); } else { char * aend; unsigned long rn = strtoul (start+1, &aend, 16); if ( aend != sep ) { strcpy (reply, "E01"); } else if ( rn > sizeof (regnames) / sizeof (regnames[0]) ) { strcpy (reply, "E04"); } else { int i; char * res; unsigned long rv = strtoul (sep+1, NULL, 16); sprintf (reply, "rm %%%s ", regnames[rn]); for ( i=0; i < sizeof (int); i++ ) { char x2[3]; sprintf (x2, "%02x", rv & 0xFFU); rv >>= 8; strcat (reply, x2); } if ( (res = kdb_request (kdb, reply)) == NULL ) { putgdbpkt (pm, "E02"); } else { if ( strstr (res, "diag:") != 0 ) { /* We don't expect anything back, so it's * an error */ putgdbpkt (pm, "E03"); } else { putgdbpkt (pm, "OK"); } free (res); } } } break; case 'g': if ( start[1] != '#' ) { putgdbpkt (pm, "E01"); } else { char * res = kdb_request (kdb, "rd"); if ( res == NULL ) { putgdbpkt (pm, "E02"); } else { int r; for ( r=0; regnames[r] != NULL; r++ ) { char * p = strstr (res, regnames[r]); if ( p != NULL && isspace (p[-1])){ int b = strlen(regnames[r])+2; unsigned long rv = strtoul (p+b, NULL, 0); for ( b=0; b < sizeof (int); b++ ) { char x2[3]; sprintf (x2, "%02x", (rv & 0xFFU)); strcat (reply, x2); rv >>= 8; } } else { strcat (reply, "xxxxxxxx"); } } putgdbpkt (pm, reply); free (res); } } break; case 'q': /* Query packet - needs further processing */ switch ( start[1] ) { case 'C': putgdbpkt (pm, "QC0"); break; case 'O': /* We don't use any special offsets, so whatever * is in the elf, should be fine. */ putgdbpkt (pm, "Text=00000000;Data=00000000;Bss=00000000;"); break; case 'R': /* Remote Command */ if ( (sep = strchr (start, ',')) == NULL ) { putgdbpkt (pm, "E01"); } else { int i; for ( i=0,sep++; sep[0] != '#' && sep < end; sep+=2,i++ ) { if ( isxdigit (sep[0]) && isxdigit (sep[1]) ) { char x2[3] = {sep[0], sep[1], '\0'}; unsigned long ch = strtoul (x2, NULL, 16); reply[i] = (ch & 0xFFU); } else { i = -1; break; } } if ( i < 0 ) { putgdbpkt (pm, "E02"); } else { const char * xchars = "0123456789ABCDEF"; char * res = kdb_request (kdb, reply); if ( res != NULL ) { for (i=0; res[i] && (i*2 < SKDB_MAX_REQSIZ); i++) { reply[i*2] = xchars[(res[i] >> 4) & 0xFU]; reply[i*2+1] = xchars[(res[i] & 0xFU)]; } reply[i*2] = '\0'; strcat (reply, "0A0D"); i += 2; if ( i*2 > 256 ) { /* Have to break the reply as gdb * cannot cope with the big packets */ char part[256]; int j; for ( j=0; j < (i*2)-254; j += 254 ) { part[0] = 'O'; memcpy (part+1, reply + j, 254); part[255] = '\0'; putgdbpkt (pm, part); } putgdbpkt (pm, reply+j); } else { putgdbpkt (pm, reply); } free (res); } else { putgdbpkt (pm, "E02"); } } } break; default: putgdbpkt (pm, "E33"); break; } break; case 'z': /* Clear a break/watch point */ bpaddr = strtoul (start+3, NULL, 16); for ( i=0; i < breaks; i++ ) { if ( breakaddrs[i] == bpaddr ) { char * res; sprintf (reply, "bc %d", i); if ( (res = kdb_request (kdb, reply)) != NULL ) { bpaddr = 0; putgdbpkt (pm, "OK"); free (res); } else { putgdbpkt (pm, "E05"); } break; } } if ( i >= breaks ) { putgdbpkt (pm, "E06"); } break; case 'Z': /* Breakpoint/watchpoint - Z,, */ bpaddr = strtoul (start+3, NULL, 16); switch ( start[1] ) { case '0': /* Software breakpoint */ for ( i=0; i < breaks; i++ ) { if ( breakaddrs[i] == bpaddr ) { putgdbpkt (pm, "OK"); break; } } if ( i >= breaks ) { char * res; sprintf (reply, "bp 0x%x", bpaddr); if ( (res = kdb_request (kdb, reply)) != NULL ) { char * bpnum; if ( (bpnum = strstr (res, "BP #")) == NULL ) { putgdbpkt (pm, "E03"); } else { int bp = strtol (bpnum+4, NULL, 0); if ( breaks <= bp) { unsigned long * nb; if ( (nb = realloc (breakaddrs, sizeof (int)*(bp+1))) != NULL ) { breakaddrs = nb; for ( i=breaks+1; i < bp; i++ ) { breakaddrs[i] = 0; } breaks = bp+1; breakaddrs[bp] = bpaddr; putgdbpkt (pm, "OK"); } else { putgdbpkt (pm, "E05"); } } free (res); } } else { putgdbpkt (pm, "E02"); } } break; case '1': /* Hardware breakpoint */ sprintf (reply, "bph 0x%8.8s", start+3); if ( kdb_request (kdb, reply) != NULL ) { putgdbpkt (pm, "OK"); } else { putgdbpkt (pm, "E02"); } break; default: putgdbpkt (pm, "E34"); break; } break; case '?': putgdbpkt (pm, "S05"); break; default: putgdbpkt (pm, "E35"); break; } } } /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\ * Function: pfork * Create a master/slave pty pair, fork and exec gdb with * -x fudged to point it to the slave pty in the parent * process space. Child will do the real work. * Parameters: * argc - number of gdb command line parameters * args - gdb's command line parameters * Returns: * file descriptor for master PTY on success or -1 on error \* * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ int pfork (int argc, char ** args) { int pt; if ( (pt = open ("/dev/ptmx", O_RDWR)) >= 0 ) { if ( grantpt (pt) != -1 ) { if ( unlockpt (pt) != -1 ) { FILE * tf; char * tname = strdup (tmpnam (NULL)); pid_t child; if ( tname == NULL ) { puts ("Oops!"); return -1; } else if ( (tf = fopen (tname, "w")) == NULL ) { perror (tname); free (tname); return -1; } fprintf (tf, "shell rm %s\n" "set remotedebug %d\n" "set serialdebug %d\n" "target remote %s\n" "define lsmod\n" "set $mod = (struct module*)module_list\n" "while $mod != &kernel_module\n" "printf \"%%p\t%%s\\n\", (long)$mod, ($mod)->name\n" "set $mod = $mod->next\n" "end\nend\n", tname, ((debug & SKDB_DBG_REMOTE) != 0), ((debug & SKDB_DBG_SERIAL) != 0), ptsname(pt)); fflush (tf); if ( (child = fork ()) > 0 ) { int i; char **gargs = calloc (argc+5, sizeof (char *)); if ( gargs == NULL ) { kill (child, SIGTERM); exit (1); } else { gargs[0] = "gdb"; gargs[1] = "-q"; gargs[2] = "-x"; gargs[3] = tname; close (pt); for ( i=0; i < argc ; i++ ) { gargs[i+4] = args[i]; } gargs[i+4] = NULL; execvp ("gdb", gargs); kill (child, SIGTERM); exit (1); } /*NOTREACHED*/ } else if ( child < 0 ) { perror ("fork"); close (pt); pt = -1; } fclose (tf); free (tname); return (pt); } else { perror ("unlockpt"); } } else { perror ("grantpt"); } close (pt); } return (-1); } static void usage (char * pname) { printf ("USAGE: %s [-Dall,serial,telnet] [-k] [-l tty] -- [gdb-args]\n", pname); puts ("Options:"); puts ("-k target is already in kdb, don't break in"); puts ("-l tty tty:speed or host:port to get access to"); puts (" a target"); } int main (int argc, char * argv[]) { int c, pm, kdb; char * line = "/dev/ttyS0"; int speed = B38400; char * delim; struct stat st; if ( argc == 2 && argv[1][0] == '-' && argv[1][1] == '?' ) { usage (argv[0]); exit (0); } while ( (c = getopt (argc, argv, "D:kl:")) > 0 ) { switch ( c ) { case 'k': isRunning = 0; break; case 'l': line = optarg; break; case 'D': delim = optarg; do { char * nextcomma; int i; if ( (nextcomma = strchr (delim, ',')) == NULL ) { nextcomma = delim + strlen (delim); } for ( i=0; dopt[i] != NULL; i++ ) { if ( ! strncmp (delim, dopt[i], nextcomma-delim)) { if ( i ) { debug |= 1 << i; } else { debug = 0xffffffffUL; } break; } } if ( dopt[i] == NULL ) { fprintf (stderr, "Unknown debug option: %s\n", delim); exit (1); } delim = nextcomma+1; } while ( (delim - optarg) < strlen (optarg) ); break; default: usage (argv[0]); exit (1); } } if ( (delim = strchr (line, ':')) != NULL ) { *delim++ = '\0'; } /* Try to guess if we're dealing with real line or with a host name */ if ( (stat (line, &st) >= 0) && S_ISCHR (st.st_mode) ) { if ( (kdb = open (line, O_RDWR)) < 0 ) { perror (line); exit (1); } else { struct termios tio; if ( tcgetattr (kdb, & tio) < 0 ) { perror ("tcgetattr"); return (1); } else { tio.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG); tio.c_cflag &= ~(CBAUD | CSIZE | PARENB | CSTOPB | CRTSCTS ); tio.c_cflag |= B38400 | CS8 | CREAD | HUPCL; tio.c_iflag &= ~(BRKINT | ICRNL |INPCK | ISTRIP); tio.c_iflag |= IXON |IXOFF; tio.c_oflag &= ~OPOST; cfsetispeed (& tio, B38400); cfsetospeed (& tio, B38400); tio.c_cc[VMIN] = 1; tio.c_cc[VTIME] = 0; if ( tcsetattr (kdb, TCSANOW, & tio) < 0 ) { perror ("tcsetattr"); exit (1); } } } } else { /* Must be a host name - try to resolve it. Note, that host must * have a port number - defaulting to a telnet port isn't going to do * us much good here */ if ( delim == NULL ) { fputs ("Host specification requires a port number\n", stderr); exit (1); } else { static struct sockaddr_in sa; struct servent * sp; struct hostent * he; char **p; memset ( & sa, 0, sizeof (sa)); sa.sin_family = AF_INET; if ( (sp = getservbyname (delim, "tcp")) != NULL ) { sa.sin_port = htons (sp->s_port); } else { /* Lookup fails. Check if it's a number */ char * err = NULL; sa.sin_port = htons ((short int)strtol (delim, & err, 0)); if ( (err == NULL) || (*err != '\0') ) { fprintf (stderr, "Cannot find port number for port %s\n", delim); exit (1); } } if ( (he = gethostbyname (line)) == NULL ) { fprintf (stderr,"No address information for %s\n", line); exit (1); } else { memcpy (& sa.sin_addr.s_addr, * he->h_addr_list, sizeof (sa.sin_addr.s_addr)); } if ( (kdb = socket (AF_INET, SOCK_STREAM, 0)) < 0 ) { perror ("socket"); exit (1); } else { if ( connect (kdb, (struct sockaddr *)&sa, sizeof (sa)) < 0 ) { fprintf (stderr, "Cannot connect to %s - %s\n", line, strerror (errno)); exit (1); } else { /* Assume telnetd connection and try to negotiate: * reply WONT to any DOs, reply DONT to any WILL * except WILL ECHO. First non-escaped charachter stops * negotiation */ int negotiate = 1; int echo = 0; telnetmode = 1; while ( negotiate ) { fd_set fds; struct timeval tv; unsigned char negbuf[512]; int bc = 0; FD_ZERO (&fds); FD_SET (kdb, &fds); tv.tv_sec = 1; tv.tv_usec = 0; if ( select (kdb+1, &fds, NULL, NULL, &tv) > 0 ) { int nb = read (kdb, negbuf+bc, 511-bc); unsigned char rep[512], * prep = rep; int i; if ( nb > 0 && ((bc + nb) < 512)) { bc += nb; for (i=0; i < bc-2; i+= 3 ) { if ( negbuf[i] == IAC ) { switch ( negbuf[i+1] ) { case DO: if ( debug & SKDB_DBG_TELNET ) { printf ("RECV DO %s\n", telopts[negbuf[i+2]]); } prep[0] = IAC; prep[1] = WONT; prep[2] = negbuf[i+2]; prep += 3; break; case WILL: if ( debug & SKDB_DBG_TELNET ) { printf ("RECV WILL %s\n", telopts[negbuf[i+2]]); } prep[0] = IAC; prep[2] = negbuf[i+2]; if ( negbuf[i+2] != TELOPT_ECHO ) { prep[1] = DONT; } else { if ( echo ) { prep -= 3; } else { echo = 1; prep[1] = DO; } } prep += 3; break; } } else { negotiate = 0; break; } } if ( ! echo ) { prep[0] = IAC; prep[1] = DO; prep[2] = TELOPT_ECHO; prep += 3; echo = 1; } if ( debug & SKDB_DBG_TELNET ) { for ( i=0; i < prep - rep; i += 3 ) { printf ("SEND %s %s\n", TELCMD((rep[i+1])), TELOPT(rep[i+2])); } } write (kdb, rep, prep - rep); } else { fputs ("Connection closed by remote host\n", stderr); exit (1); } } else { /* Timeout - other end doesn't want * to negotiate no more */ negotiate = 0; } } } } } } if ( (pm = pfork (argc-optind, argv+optind)) >= 0 ) { int maxfd = (pm > kdb) ? pm : kdb; int bc = 0; char kdbpkt[SKDB_MAX_REQSIZ]; signal (SIGINT, SIG_IGN); while ( 1 ) { fd_set fds; FD_SET(pm, &fds); FD_SET(kdb, &fds); if (select (maxfd+1, &fds, NULL, NULL, NULL) < 0 ) { close (pm); break; } else { int i, sz; if ( FD_ISSET (pm, &fds) ) { char pkt[SKDB_MAX_REQSIZ]; if ( (sz = read (pm, pkt, SKDB_MAX_REQSIZ)) <= 0 ) { break; } pkt[sz] = '\0'; /* Sometimes gdb doesn't play by the rules and * doesn't sent packets but sends Ctrl-C instead, * which is naughty but it does it, so we check * for this case before we start processing good * packets */ if ( pkt[0] == '\3' ) { /* GDB sent us an interrupt */ kdb_request (kdb, ""); putgdbpkt (pm, "S02"); } else { gdb_process (pm, kdb, pkt); } } if ( FD_ISSET (kdb, &fds) ) { if ( (sz = read (kdb, kdbpkt+bc, SKDB_MAX_REQSIZ - bc)) >= 0 ) { char * prompt; bc += sz; kdbpkt[bc] = '\0'; if ( telnetmode ) { char * nul; while ((nul=memchr (kdbpkt, '\0', bc)) != NULL) { memmove (nul, nul+1, kdbpkt+bc-nul-1); bc--; } } if ( (prompt = strstr (kdbpkt, "kdb> ")) != NULL ) { isRunning = 0; if ( strstr (kdbpkt, "due to Keyboard Entry") != NULL ) putgdbpkt (pm, "S02"); else if ( strstr (kdbpkt, "due to Breakpoint") != NULL ) putgdbpkt (pm, "S05"); else putgdbpkt (pm, "S00"); bc -= prompt+5 - kdbpkt; memmove (kdbpkt, prompt+5, bc); } else { if ( (SKDB_MAX_REQSIZ - bc) < 5 ) { memmove (kdbpkt, kdbpkt+bc-5, 5); bc = 5; } } } } } } } close (pm); close (kdb); return (0); } From owner-kdb@oss.sgi.com Thu Nov 9 16:34:11 2000 Received: by oss.sgi.com id ; Thu, 9 Nov 2000 16:34:02 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:58669 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 9 Nov 2000 16:33:51 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA23916 for ; Thu, 9 Nov 2000 16:25:56 -0800 (PST) mail_from (max@kuku.melbourne.sgi.com) Received: from kuku.melbourne.sgi.com (kuku.melbourne.sgi.com [134.14.55.163]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22661; Fri, 10 Nov 2000 11:31:14 +1100 Received: (from max@localhost) by kuku.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA18689; Fri, 10 Nov 2000 11:31:12 +1100 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14859.16847.793203.195429@kuku.melbourne.sgi.com> Date: Fri, 10 Nov 2000 11:31:11 +1100 (EST) From: Max Matveev To: Ray Bryant Cc: kdb@oss.sgi.com Subject: Re: Source level debugging with kdb In-Reply-To: <3A0ABBCB.98615F60@austin.ibm.com> References: <3A0ABBCB.98615F60@austin.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing Ray, First of all, I'll copy this replay to kdb@oss.sgi.com - hopefully some(one) will add more to that I know. >>>>> "RB" == Ray Bryant writes: RB> Max Matveev wrote: >> Some of you may remember that Keith mentioned a possibility of having >> source level debugging with kdb via proxy. I finally dragged myself to >> writing a little Readme note about it so it can be used by somebody >> other then myself. Here it is. >> >> Source level debugging with kdb >> RB> Can some explain the advantages of doing remote debugging via kdb RB> instead of by kgdb? kdb can do backtraces without aid of frame pointers and it actually works as opposed to gdb (and kgdb, since kgdb is only a remote proxy for gdb). What alone is worth a lot. Alas, kdb doesn't know much about symbols and structures that's the reason why we wanted to add gdb to the picture. max PS. And we like to have Keith here so having a little something he can work on is of the upmost importance. PPS. Darn, that tongue did stack in de cheek. From owner-kdb@oss.sgi.com Thu Nov 9 16:56:42 2000 Received: by oss.sgi.com id ; Thu, 9 Nov 2000 16:56:31 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:65078 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 9 Nov 2000 16:56:11 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA28235 for ; Thu, 9 Nov 2000 16:48:20 -0800 (PST) mail_from (sfoehner@illini.engr.sgi.com) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA43028 for ; Thu, 9 Nov 2000 16:55:41 -0800 (PST) Received: from illini.engr.sgi.com (illini.engr.sgi.com [163.154.5.81]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA83796; Thu, 9 Nov 2000 16:53:08 -0800 (PST) Received: (from sfoehner@localhost) by illini.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA98988; Thu, 9 Nov 2000 16:52:47 -0800 (PST) Date: Thu, 9 Nov 2000 16:52:47 -0800 (PST) From: sfoehner@illini.engr.sgi.com (Scott Foehner) Message-Id: <10011091652.ZM1200582@illini.engr.sgi.com> In-Reply-To: Max Matveev "Re: Source level debugging with kdb" (Nov 10, 11:31am) References: <3A0ABBCB.98615F60@austin.ibm.com> <14859.16847.793203.195429@kuku.melbourne.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: Max Matveev , Ray Bryant Subject: Re: Source level debugging with kdb Cc: kdb@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing On Nov 10, 11:31am, Max Matveev wrote: > Subject: Re: Source level debugging with kdb > > Ray, > > First of all, I'll copy this replay to kdb@oss.sgi.com - hopefully > some(one) will add more to that I know. > RB> Can some explain the advantages of doing remote debugging via kdb > RB> instead of by kgdb? > kdb can do backtraces without aid of frame pointers and it > actually works as opposed to gdb (and kgdb, since kgdb is only a > remote proxy for gdb). What alone is worth a lot. I would say this is the big one. Also, with Keith's set up, you can access the kdb commands via "mon" to get to things that the kernel would know about, but gdb probably doesn't. An example might be certain MMU registers that can't be read from user-land, or many of the different types of registers that are only able to be accessed by the kernel in IA64. I was talking to Keith's and Max's manager about this recently, too. He told me that the stack tracebacks in the kernel might be strange enough that gdb could not handle them as well as kdb, which would have more knowledge since it is actually part of the kernel. He said this was especially true for IA64 tracebacks. Maybe Keith would know more here. That's all I can think of off hand. Oh, there might be some issues with modules. I think kdb understands modules, but I am not sure anymore. Maybe Keith or Max can answer that. However, I believe newer versions of gdb also understand modules, so that may be a moot point. I certainly know of people using kgdb to debug modules. Hope this helps, Scott -- Scott Foehner SGI sfoehner@engr.sgi.com Computer Systems Business Unit 650-933-3473 Core OS From owner-kdb@oss.sgi.com Fri Nov 10 09:18:17 2000 Received: by oss.sgi.com id ; Fri, 10 Nov 2000 09:17:58 -0800 Received: from firewall.cobalt.com ([63.77.128.251]:58865 "EHLO oscar0.cobalt.com") by oss.sgi.com with ESMTP id ; Fri, 10 Nov 2000 09:17:48 -0800 Received: (from ajones@localhost) by oscar0.cobalt.com (8.9.3/8.9.3) id KAA08629 for kdb@oss.sgi.com; Fri, 10 Nov 2000 10:12:55 -0800 From: ajones@cobalt.com Message-Id: <200011101812.KAA08629@oscar0.cobalt.com> Subject: backtrace question To: kdb@oss.sgi.com Date: Fri, 10 Nov 2000 10:12:55 -0800 (PST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing I'm frustrated by the backtrace function in kdb for the 2.2.13 kernel. The module I'm working with only seems to compile with -O2. However, kdb's bt seems to be confused by the call stacks used with -O2 and it gives up early. Has there been any work to improve the backtrace function since the 2.2.13 release? With the Solaris kdb I used to hunt for stack pointers in the stack bejond a trap were kdb gives up. It might be useful to automate this function; have bt scan a couple of hundred bytes to look for signs of a stack frame; pointers near their address next (into the stack) next to pointers near known symbols (return pointers). Alan Jones From owner-kdb@oss.sgi.com Fri Nov 10 09:32:08 2000 Received: by oss.sgi.com id ; Fri, 10 Nov 2000 09:31:58 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:34579 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Fri, 10 Nov 2000 09:31:53 -0800 Received: (qmail 27296 invoked from network); 10 Nov 2000 17:31:47 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 10 Nov 2000 17:31:47 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: ajones@cobalt.com cc: kdb@oss.sgi.com Subject: Re: backtrace question In-reply-to: Your message of "Fri, 10 Nov 2000 10:12:55 -0800." <200011101812.KAA08629@oscar0.cobalt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Nov 2000 04:31:46 +1100 Message-ID: <7803.973877506@ocs3.ocs-net> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing On Fri, 10 Nov 2000 10:12:55 -0800 (PST), ajones@cobalt.com wrote: >I'm frustrated by the backtrace function in kdb for the 2.2.13 kernel. >The module I'm working with only seems to compile with -O2. However, >kdb's bt seems to be confused by the call stacks used with -O2 and >it gives up early. Has there been any work to improve the backtrace >function since the 2.2.13 release? There is an unofficial backport of kdb v1.5 to 2.2.18-pre15 in ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.5-2.2.18-pre15.gz It is not being supported nor updated to new 2.2 kernels. >With the Solaris kdb I used to hunt for stack pointers in the stack >bejond a trap were kdb gives up. It might be useful to automate this >function; have bt scan a couple of hundred bytes to look for >signs of a stack frame; pointers near their address next (into the >stack) next to pointers near known symbols (return pointers). Read the comments in kdb about ix86 stack frames, they are horrible. "mds %esp" is useful to manually back track. From owner-kdb@oss.sgi.com Tue Nov 14 09:41:58 2000 Received: by oss.sgi.com id ; Tue, 14 Nov 2000 09:41:38 -0800 Received: from firewall.cobalt.com ([63.77.128.251]:33783 "EHLO oscar0.cobalt.com") by oss.sgi.com with ESMTP id ; Tue, 14 Nov 2000 09:41:08 -0800 Received: (from ajones@localhost) by oscar0.cobalt.com (8.9.3/8.9.3) id KAA13424 for kdb@oss.sgi.com; Tue, 14 Nov 2000 10:36:04 -0800 From: ajones@cobalt.com Message-Id: <200011141836.KAA13424@oscar0.cobalt.com> Subject: kdb v1.5 on 2.2.* To: kdb@oss.sgi.com Date: Tue, 14 Nov 2000 10:36:03 -0800 (PST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing I've got SGI's kdb 1.5 mostly working on a Cobalt derivative of 2.2.16. If there are others working with or interested in kdb 1.5 on 2.2.*, I'd be happy to share experiences. I prefer kdb 1.5 over the published 2.2.13 kdb for two reasons: backspace key, more complete backtrace. Regards, Alan From owner-kdb@oss.sgi.com Fri Nov 17 00:41:41 2000 Received: by oss.sgi.com id ; Fri, 17 Nov 2000 00:41:32 -0800 Received: from ausmtp02.au.ibm.COM ([202.135.136.105]:7696 "EHLO ausmtp02.au.ibm.com") by oss.sgi.com with ESMTP id ; Fri, 17 Nov 2000 00:41:17 -0800 Received: from f03n07e.au.ibm.com by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id TAA279510 for ; Fri, 17 Nov 2000 19:33:28 +1100 From: aprasad@in.ibm.com Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n07e.au.ibm.com (8.8.8m3/NCO v4.95) with SMTP id TAA28450 for ; Fri, 17 Nov 2000 19:41:11 +1100 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA25699A.002FB45E ; Fri, 17 Nov 2000 19:41:03 +1100 X-Lotus-FromDomain: IBMIN@IBMAU To: kdb@oss.sgi.com Message-ID: Date: Fri, 17 Nov 2000 14:04:50 +0530 Subject: keyboard lockup after kdb session Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing Hi all, After kdb session is over. my keyboard gets locked, tough linux kept running, i am able to reboot the system via network. To come out of kdb i use go command. I am running 2.4test10 kernel with p3/I815 motherboard. Can anybody provide some help in restoring the keyboard without rebooting the system, thanks, Anil Note: Please CC the answer From owner-kdb@oss.sgi.com Fri Nov 17 10:35:44 2000 Received: by oss.sgi.com id ; Fri, 17 Nov 2000 10:35:35 -0800 Received: from firewall.cobalt.com ([63.77.128.251]:37879 "EHLO oscar0.cobalt.com") by oss.sgi.com with ESMTP id ; Fri, 17 Nov 2000 10:35:23 -0800 Received: (from ajones@localhost) by oscar0.cobalt.com (8.9.3/8.9.3) id LAA25502; Fri, 17 Nov 2000 11:30:04 -0800 From: ajones@cobalt.com Message-Id: <200011171930.LAA25502@oscar0.cobalt.com> Subject: Re: keyboard lockup after kdb session To: aprasad@in.ibm.com Date: Fri, 17 Nov 2000 11:30:04 -0800 (PST) Cc: kdb@oss.sgi.com In-Reply-To: from "aprasad@in.ibm.com" at Nov 17, 2000 02:04:50 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing In my attempt at porting kdb 1.5 to 2.2.16, I also ran into trouble with "go" from kdb. Except in my case the system paniced and there was some evidence of corruption. I now have prints on entry and exit to kdb_setjmp() and kdb_longjmp() and the problem magically disappeared. It is also suspicious that the static strings in the prints seem to get corrupted. Don't know if this is related. You might try to get into the debugger a second time, either with Ctrl-A or a break point or trap keyed off of commands from a network session. Then review the ps and see if you can identify the thread(s) that is(are) stuck. Alan > Hi all, > After kdb session is over. my keyboard gets locked, tough linux kept > running, i am able to reboot the system via network. > To come out of kdb i use go command. I am running 2.4test10 kernel with > p3/I815 motherboard. > Can anybody provide some help in restoring the keyboard without rebooting > the system, > thanks, > Anil > Note: Please CC the answer > From owner-kdb@oss.sgi.com Fri Nov 17 20:39:40 2000 Received: by oss.sgi.com id ; Fri, 17 Nov 2000 20:39:31 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:31756 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Fri, 17 Nov 2000 20:39:13 -0800 Received: (qmail 4845 invoked from network); 18 Nov 2000 04:39:05 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 18 Nov 2000 04:39:05 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Tigran Aivazian cc: linux-kernel@vger.kernel.org, kdb@oss.sgi.com, aprasad@in.ibm.com Subject: Re: test11-pre6 still very broken In-reply-to: Your message of "Fri, 17 Nov 2000 20:00:49 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Nov 2000 15:38:59 +1100 Message-ID: <20616.974522339@ocs3.ocs-net> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing On Fri, 17 Nov 2000 20:00:49 +0000 (GMT), Tigran Aivazian wrote: >The mysterious lockups in test11-pre5 continue in test11-pre6. It is very >difficult because the lockups appear to be kdb-specific (and kdb itself >goes mad) but when there is no kdb there is very little useful information >one can extract from a dead system... ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.6-2.4.0-test11-pre7.gz Assorted bug fixes from my work in progress tree, including one that fixes a race between user space use of debug and kdb, ltrace trips this. Some people have reported keyboard lockups after leaving kdb. I have not been able to reproduce this problem, let me know if you still see it. From owner-kdb@oss.sgi.com Mon Nov 20 07:51:55 2000 Received: by oss.sgi.com id ; Mon, 20 Nov 2000 07:51:45 -0800 Received: from web312.mail.yahoo.com ([216.115.105.77]:20493 "HELO web312.mail.yahoo.com") by oss.sgi.com with SMTP id ; Mon, 20 Nov 2000 07:51:32 -0800 Message-ID: <20001120155127.9902.qmail@web312.mail.yahoo.com> Received: from [208.41.149.143] by web312.mail.yahoo.com; Mon, 20 Nov 2000 07:51:27 PST Date: Mon, 20 Nov 2000 07:51:27 -0800 (PST) From: hung wong Subject: problem with booting To: kdb@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing my system is running 2.2.14 with intel processor. i downloaded the 2.2.13 linux kernel source and v0.6-2.2.13 kdb from SGI. i was able to build a kernel. the problem is that the kernel with KDB failed to boot with the following message: Lilo boot: klinux Loading klinux ............ Uncompressing Linux .... ran out of input data -- System halted do you have any idea what cause the problem ?? i also tried increased the CONFIG_KDB_STBSIZE from 8000 (which is the default value in xconfig) to 80000 and the problem stays. thanks! hung ping wong __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ From owner-kdb@oss.sgi.com Mon Nov 20 10:48:36 2000 Received: by oss.sgi.com id ; Mon, 20 Nov 2000 10:48:16 -0800 Received: from firewall.cobalt.com ([63.77.128.251]:36090 "EHLO oscar0.cobalt.com") by oss.sgi.com with ESMTP id ; Mon, 20 Nov 2000 10:47:53 -0800 Received: (from ajones@localhost) by oscar0.cobalt.com (8.9.3/8.9.3) id LAA10083; Mon, 20 Nov 2000 11:39:12 -0800 From: ajones@cobalt.com Message-Id: <200011201939.LAA10083@oscar0.cobalt.com> Subject: Re: problem with booting To: hpw11@yahoo.com (hung wong) Date: Mon, 20 Nov 2000 11:39:12 -0800 (PST) Cc: kdb@oss.sgi.com In-Reply-To: <20001120155127.9902.qmail@web312.mail.yahoo.com> from "hung wong" at Nov 20, 2000 07:51:27 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing I've used this version of kdb successfully with 2.2.14 with the CONFIG_KDB_STBSIZE of 9000. Note that the patch is not "clean" and must be hand merged. If I remember the hardest merge was serial.c. I've never seen the error you mentioned. Alan > my system is running 2.2.14 with intel processor. > > i downloaded the 2.2.13 linux kernel source and > v0.6-2.2.13 kdb from SGI. i was able to build a > kernel. > > the problem is that the kernel with KDB failed to > boot with the following message: > > Lilo boot: klinux > Loading klinux ............ > Uncompressing Linux .... > ran out of input data > > -- System halted > > do you have any idea what cause the problem ?? > > i also tried increased the CONFIG_KDB_STBSIZE from > 8000 > (which is the default value in xconfig) to 80000 and > the problem stays. > > thanks! > hung ping wong > > __________________________________________________ > Do You Yahoo!? > Yahoo! Calendar - Get organized for the holidays! > http://calendar.yahoo.com/ > From owner-kdb@oss.sgi.com Mon Nov 20 15:27:47 2000 Received: by oss.sgi.com id ; Mon, 20 Nov 2000 15:27:28 -0800 Received: from ganymede.or.intel.com ([134.134.248.3]:11273 "EHLO ganymede.or.intel.com") by oss.sgi.com with ESMTP id ; Mon, 20 Nov 2000 15:27:24 -0800 Received: from shiva.hf.intel.com (shiva.hf.intel.com [143.181.230.2]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with ESMTP id PAA04811 for ; Mon, 20 Nov 2000 15:27:23 -0800 (PST) Received: from intel.com ([10.8.155.130]) by shiva.hf.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id PAA28290 for ; Mon, 20 Nov 2000 15:27:20 -0800 (PST) Message-ID: <3A19B399.7E11BA10@intel.com> Date: Mon, 20 Nov 2000 15:28:25 -0800 From: Randy Dunlap X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.0-test11 i686) X-Accept-Language: en MIME-Version: 1.0 To: kdb@oss.sgi.com Subject: kdb-v1.6 for 2.4.0-test11 ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing Hi, I'm having compile errors with kdb-v1.6-2.4.0-test11-pre7... but I'm trying to use it on 2.4.0-test11. I haven't seen any traffic about this. Is kdb available for 2.4.0-test11? ix86 uniproc. Maybe I'm the only person not using SMP? First error is in arch/kernel/i386/io-apic.c, line 1608, x86_capability |= constant; needs to be x86_capability[0] |= constant; After this, arch/i386/kdb/i386-dis.c has a few errors (sample): gcc -D__KERNEL__ -I/work/linsrc/240-test11/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -march=i686 -c -o i386-dis.o i386-dis.c i386-dis.c: In function `print_insn_i386': i386-dis.c:2143: `bfd_mach_i386_i386_intel_syntax' undeclared (first use in this function) i386-dis.c:2143: (Each undeclared identifier is reported only once i386-dis.c:2143: for each function it appears in.) i386-dis.c: In function `OP_ST': i386-dis.c:2757: parse error before `ATTRIBUTE_UNUSED' i386-dis.c:2758: parse error before `ATTRIBUTE_UNUSED' i386-dis.c: In function `OP_STi': i386-dis.c:2766: parse error before `ATTRIBUTE_UNUSED' i386-dis.c:2767: parse error before `ATTRIBUTE_UNUSED' i386-dis.c: In function `OP_SEG': i386-dis.c:3422: parse error before `ATTRIBUTE_UNUSED' i386-dis.c:3423: parse error before `ATTRIBUTE_UNUSED' i386-dis.c: In function `OP_DIR': i386-dis.c:3435: parse error before `ATTRIBUTE_UNUSED' i386-dis.c: In function `OP_OFF': i386-dis.c:3458: parse error before `ATTRIBUTE_UNUSED' i386-dis.c: In function `OP_C': i386-dis.c:3527: parse error before `ATTRIBUTE_UNUSED' i386-dis.c:3528: parse error before `ATTRIBUTE_UNUSED' i386-dis.c: In function `OP_D': i386-dis.c:3537: parse error before `ATTRIBUTE_UNUSED' gcc is 2.91.66 (egcs 1.1.2) TIA. ~Randy -- _______________________________________________ |randy.dunlap_at_intel.com 503-677-5408| |NOTE: Any views presented here are mine alone| |& may not represent the views of my employer.| ----------------------------------------------- From owner-kdb@oss.sgi.com Mon Nov 20 15:35:48 2000 Received: by oss.sgi.com id ; Mon, 20 Nov 2000 15:35:28 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:14162 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 20 Nov 2000 15:35:20 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA08022 for ; Mon, 20 Nov 2000 15:27:26 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA12620; Tue, 21 Nov 2000 10:34:00 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Randy Dunlap cc: kdb@oss.sgi.com Subject: Re: kdb-v1.6 for 2.4.0-test11 ? In-reply-to: Your message of "Mon, 20 Nov 2000 15:28:25 -0800." <3A19B399.7E11BA10@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 10:33:59 +1100 Message-ID: <2203.974763239@kao2.melbourne.sgi.com> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing On Mon, 20 Nov 2000 15:28:25 -0800, Randy Dunlap wrote: >I'm having compile errors with kdb-v1.6-2.4.0-test11-pre7... >but I'm trying to use it on 2.4.0-test11. >I haven't seen any traffic about this. >Is kdb available for 2.4.0-test11? Shortly, once I fix some problems. >First error is in arch/kernel/i386/io-apic.c, line 1608, > x86_capability |= constant; >needs to be > x86_capability[0] |= constant; - boot_cpu_data.x86_capability |= X86_FEATURE_APIC; + set_bit(X86_FEATURE_APIC, &boot_cpu_data.x86_capability); >After this, arch/i386/kdb/i386-dis.c has a few errors (sample): > >gcc -D__KERNEL__ -I/work/linsrc/240-test11/include -Wall >-Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -march=i686 -c -o >i386-dis.o i386-dis.c >i386-dis.c: In function `print_insn_i386': >i386-dis.c:2143: `bfd_mach_i386_i386_intel_syntax' undeclared (first use >in this function) Defined in /usr/include/bfd.h, mine is binutils-2.9.5.0.22-6. The disassembly code in kdb was upgraded to a recent gdb, you probably need to upgrade binutils. From owner-kdb@oss.sgi.com Mon Nov 20 18:27:27 2000 Received: by oss.sgi.com id ; Mon, 20 Nov 2000 18:27:08 -0800 Received: from [159.226.38.2] ([159.226.38.2]:29958 "EHLO mail.cti.com.cn") convert rfc822-to-8bit22a by oss.sgi.com with ESMTP id ; Mon, 20 Nov 2000 18:26:51 -0800 Received: from pc51 ([200.121.2.51]) by mail.cti.com.cn (8.7.5/8.7.3) with SMTP id KAA27841; Tue, 21 Nov 2000 10:21:47 +0800 Message-ID: <001301c05361$e02491c0$330279c8@pc51> From: "lhyang" To: "hung wong" Cc: References: <20001120155127.9902.qmail@web312.mail.yahoo.com> Subject: Re: problem with booting Date: Tue, 21 Nov 2000 10:22:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing Hi HungWong, > the problem is that the kernel with KDB failed to > boot with the following message: > > Lilo boot: klinux > Loading klinux ............ > Uncompressing Linux .... > ran out of input data > > -- System halted > > do you have any idea what cause the problem ?? Maybe update the lilo, e.g. reinstall your lilo. -Jim From owner-kdb@oss.sgi.com Tue Nov 21 10:59:11 2000 Received: by oss.sgi.com id ; Tue, 21 Nov 2000 10:58:51 -0800 Received: from farmer8.nanobiz.com ([208.176.9.172]:36873 "EHLO nanobiz.com") by oss.sgi.com with ESMTP id ; Tue, 21 Nov 2000 10:58:24 -0800 Received: from pendragon.eng.nanobiz.com (IDENT:root@pendragon [192.168.1.155]) by nanobiz.com (8.9.3/8.9.3) with ESMTP id KAA20407; Tue, 21 Nov 2000 10:46:50 -0800 From: Scott Lurndal Received: by pendragon.eng.nanobiz.com; Tue, 21 Nov 2000 11:51:09 -0800 Message-Id: <200011211951.LAA20546@pendragon.eng.nanobiz.com> Subject: Re: problem with booting To: lhyang@cti.com.cn (lhyang) Date: Tue, 21 Nov 2000 11:51:09 -0800 (PST) Cc: hpw11@yahoo.com (hung wong), kdb@oss.sgi.com In-Reply-To: <001301c05361$e02491c0$330279c8@pc51> from "lhyang" at Nov 21, 2000 10:22:03 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing > > Hi HungWong, > > > the problem is that the kernel with KDB failed to > > boot with the following message: > > > > Lilo boot: klinux > > Loading klinux ............ > > Uncompressing Linux .... > > ran out of input data > > > > -- System halted > > > > do you have any idea what cause the problem ?? > > Maybe update the lilo, e.g. reinstall your lilo. This often happens when the bzImage gets corrupted or truncated while installing it on the target machine. (the gunzip code in the secondary bootstrap ran out of data while decompressing the kernel). This might also be a result of the 'HEAP_SIZE' define being too low in the bootstrap code. scott > > -Jim > From owner-kdb@oss.sgi.com Wed Nov 22 10:41:52 2000 Received: by oss.sgi.com id ; Wed, 22 Nov 2000 10:41:42 -0800 Received: from jump-isi.interactivesi.com ([207.8.4.2]:29937 "HELO dinero.interactivesi.com") by oss.sgi.com with SMTP id ; Wed, 22 Nov 2000 10:41:25 -0800 Received: (qmail 9997 invoked from network); 22 Nov 2000 18:41:24 -0000 Received: from one.interactivesi.com (ttabi@10.2.247.106) by dinero.interactivesi.com with SMTP; 22 Nov 2000 18:41:24 -0000 Date: Wed, 22 Nov 2000 12:41:24 -0600 From: Timur Tabi To: kdb@oss.sgi.com Subject: bug in 2.2.18-pre15 patch X-Mailer: The Polarbar Mailer; version=1.18; build=55 Message-Id: <20001122184136Z553678-493+1012@oss.sgi.com> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing After I apply the kdb patch to 2.2.18-pre15 and compile, I get this error: cc -D__KERNEL__ -I/usr/src/linux-2.2.18-pre15/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o init/main.o init/main.c init/main.c: In function `parse_options': init/main.c:1357: parse error before `extern' init/main.c: In function `start_kernel': init/main.c:1415: warning: implicit declaration of function `setup_arch' init/main.c:1494: warning: implicit declaration of function `cpu_idle' make: *** [init/main.o] Error 1 It appears the problem is a right-brace missing after line 1307 in main.c. This brace closes the block started on line 1284. (I'd supply a patch, but I don't know how to make one). Unfortunately, it still doesn't compile. cc -D__KERNEL__ -I/usr/src/linux-2.2.18-pre15/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DEXPORT_SYMTAB -c serial.c serial.c: In function `receive_chars': serial.c:407: `regs' undeclared (first use in this function) serial.c:407: (Each undeclared identifier is reported only once serial.c:407: for each function it appears in.) make[3]: *** [serial.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.2.18-pre15/drivers/char' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.2.18-pre15/drivers/char' make[1]: *** [_subdir_char] Error 2 make[1]: Leaving directory `/usr/src/linux-2.2.18-pre15/drivers' make: *** [_dir_drivers] Error 2 The variable "regs" is not defined anywhere. Does anyone actually test these patches before publishing them? How could such obvious errors be missed? -- Timur Tabi - ttabi@interactivesi.com Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. From owner-kdb@oss.sgi.com Wed Nov 22 13:55:49 2000 Received: by oss.sgi.com id ; Wed, 22 Nov 2000 13:55:40 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:55817 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Wed, 22 Nov 2000 13:55:28 -0800 Received: (qmail 32294 invoked from network); 22 Nov 2000 21:55:22 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Nov 2000 21:55:22 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Timur Tabi cc: kdb@oss.sgi.com Subject: Re: bug in 2.2.18-pre15 patch In-reply-to: Your message of "Wed, 22 Nov 2000 12:41:24 MDT." <20001122184136Z553678-493+1012@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Nov 2000 08:55:21 +1100 Message-ID: <3307.974930121@ocs3.ocs-net> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing On Wed, 22 Nov 2000 12:41:24 -0600, Timur Tabi wrote: >After I apply the kdb patch to 2.2.18-pre15 and compile, I get this error: The kdb-v1.5-2.2.18-pre15.gz patch on oss.sgi.com was generated from the wrong branch of the kdb source repository. I will put up a clean patch in a couple of hours, after I get to work. >Does anyone actually test these patches before publishing them? How could such >obvious errors be missed? The source repository compiles clean, it was the patch generation that was incorrect. BTW, the kdb patches for 2.2 kernels are not supported, they are only there as a courtesy. SGI only supports kdb patches for the 2.4 kernel. From owner-kdb@oss.sgi.com Sat Nov 25 11:55:29 2000 Received: by oss.sgi.com id ; Sat, 25 Nov 2000 11:55:09 -0800 Received: from jump-isi.interactivesi.com ([207.8.4.2]:50682 "HELO dinero.interactivesi.com") by oss.sgi.com with SMTP id ; Sat, 25 Nov 2000 11:54:42 -0800 Received: (qmail 23597 invoked from network); 25 Nov 2000 19:54:31 -0000 Received: from one.interactivesi.com (ttabi@10.2.247.106) by dinero.interactivesi.com with SMTP; 25 Nov 2000 19:54:31 -0000 Date: Sat, 25 Nov 2000 13:54:31 -0600 From: Timur Tabi To: kdb@oss.sgi.com In-Reply-To: <3307.974930121@ocs3.ocs-net> References: Your message of "Wed, 22 Nov 2000 12:41:24 MDT."<20001122184136Z553678-493+1012@oss.sgi.com> Subject: Re: bug in 2.2.18-pre15 patch X-Mailer: The Polarbar Mailer; version=1.18; build=55 Message-Id: <20001125195450Z553744-484+39@oss.sgi.com> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing ** Reply to message from Keith Owens on Thu, 23 Nov 2000 08:55:21 +1100 > The source repository compiles clean, it was the patch generation that > was incorrect. BTW, the kdb patches for 2.2 kernels are not supported, > they are only there as a courtesy. SGI only supports kdb patches for > the 2.4 kernel. In that case, I greatly appreciate the effort. Wasn't 2.2 supported at one point? -- Timur Tabi - ttabi@interactivesi.com Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. From owner-kdb@oss.sgi.com Sat Nov 25 16:46:24 2000 Received: by oss.sgi.com id ; Sat, 25 Nov 2000 16:46:15 -0800 Received: from ppp0.ocs.com.au ([203.34.97.3]:26628 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Sat, 25 Nov 2000 16:46:04 -0800 Received: (qmail 5325 invoked from network); 26 Nov 2000 00:45:59 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 26 Nov 2000 00:45:59 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Timur Tabi cc: kdb@oss.sgi.com Subject: Re: bug in 2.2.18-pre15 patch In-reply-to: Your message of "Sat, 25 Nov 2000 13:54:31 MDT." <20001125195450Z553744-484+39@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Nov 2000 11:45:58 +1100 Message-ID: <10759.975199558@ocs3.ocs-net> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing On Sat, 25 Nov 2000 13:54:31 -0600, Timur Tabi wrote: >** Reply to message from Keith Owens on Thu, 23 Nov >2000 08:55:21 +1100 >> The source repository compiles clean, it was the patch generation that >> was incorrect. BTW, the kdb patches for 2.2 kernels are not supported, >> they are only there as a courtesy. SGI only supports kdb patches for >> the 2.4 kernel. > >In that case, I greatly appreciate the effort. Wasn't 2.2 supported at one >point? Yes. But SGI's development effort on Linux is aimed at current kernels, not the stable ones.