From owner-kdb@oss.sgi.com Mon Apr 3 12:22:03 2000 Received: by oss.sgi.com id ; Mon, 3 Apr 2000 12:21:54 -0700 Received: from Cantor.suse.de ([194.112.123.193]:30985 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Mon, 3 Apr 2000 12:21:47 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id BB3741E1DF; Mon, 3 Apr 2000 21:21:45 +0200 (MEST) Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 37A6210A043; Mon, 3 Apr 2000 21:21:41 +0200 (MEST) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 8AB1D2F36B; Mon, 3 Apr 2000 21:21:36 +0200 (MEST) Date: Mon, 3 Apr 2000 21:21:36 +0200 From: "Andi Kleen" To: lord@sgi.com Cc: kdb@oss.sgi.com Subject: [PATCH] Updated KDB non Intel patch Message-ID: <20000403212136.A29163@gruyere.muc.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing This version of the KDB non Intel patch should apply to the latest CVS on oss.sgi.com -Andi --- linux/arch/i386/kdb/kdbasupport.c-k6kdb Sat Mar 25 01:41:33 2000 +++ linux/arch/i386/kdb/kdbasupport.c Mon Apr 3 20:50:59 2000 @@ -37,6 +37,41 @@ unsigned long smp_kdb_wait; #endif +enum cpu { IntelP5, IntelP6, AmdK6, Unknown } kdba_msrtype; + +/* The normal kernel does the same, but be independent. */ +static void +kdba_checkcpu(void) +{ + union { + char str[12]; + __u32 reg[3]; + } v; + int eax,ebx,ecx,edx; + __asm__("cpuid" + : "=a" (eax), "=b" (v.reg[0]) , "=c" (v.reg[1]), "=d" (v.reg[2]) + : "a" (0)); + __asm__("cpuid" + : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) + : "a" (1)); + + kdba_msrtype = Unknown; + if (!strcmp(v.str, "GenuineIntel")) { + switch ((ebx >> 4) & 0xF) { + case 5: + kdba_msrtype = IntelP5; + break; + case 6: + kdba_msrtype = IntelP6; + break; + } + } else if (!strcmp(v.str, "AuthenticAMD") && (((ebx >> 4) & 0xF) == 6)) { + kdba_msrtype = AmdK6; + } +} + + + void kdba_installdbreg(kdb_bp_t *bp) { @@ -708,6 +743,11 @@ { u32 lv, hv; + if (kdba_msrtype != IntelP6) { + kdb_printf("Last branch information not supported on this CPU.\n"); + return; + } + rdmsr(DEBUGCTLMSR, lv, hv); lv |= 0x1; /* Set LBR enable */ wrmsr(DEBUGCTLMSR, lv, hv); @@ -734,6 +774,11 @@ u32 bflv, bfhv; u32 btlv, bthv; + if (kdba_msrtype != IntelP6) { + kdb_printf("Last branch information not supported on this CPU.\n"); + return; + } + rdmsr(LASTBRANCHFROMIP, bflv, bfhv); rdmsr(LASTBRANCHTOIP, btlv, bthv); kdb_printf("Last Branch IP, from: 0x%x to 0x%x\n", @@ -1087,6 +1132,7 @@ void kdba_init(void) { + kdba_checkcpu(); kdba_enablelbr(); return; --- linux/arch/i386/kernel/entry.S-k6kdb Sat Mar 25 01:41:33 2000 +++ linux/arch/i386/kernel/entry.S Mon Apr 3 20:52:24 2000 @@ -432,16 +432,6 @@ jmp error_code ENTRY(page_fault) - pushl %ecx - pushl %edx - pushl %eax - movl $473,%ecx - rdmsr - andl $0xfffffffe,%eax - wrmsr - popl %eax - popl %edx - popl %ecx pushl $ SYMBOL_NAME(do_page_fault) jmp error_code From owner-kdb@oss.sgi.com Mon Apr 3 12:29:44 2000 Received: by oss.sgi.com id ; Mon, 3 Apr 2000 12:29:34 -0700 Received: from biff.ibm.net.il ([192.115.72.164]:61410 "HELO biff.ibm.net.il") by oss.sgi.com with SMTP id ; Mon, 3 Apr 2000 12:29:31 -0700 Received: from moose (host13.mucom.co.il [192.115.216.45]) by biff.ibm.net.il (Postfix) with ESMTP id B5AF21004 for ; Mon, 3 Apr 2000 22:29:06 +0300 (IDT) Date: Mon, 3 Apr 2000 21:27:16 -0200 (GMT+2) From: Marc Esipovich To: kdb@oss.sgi.com Subject: Re: [PATCH] Updated KDB non Intel patch In-Reply-To: <20000403212136.A29163@gruyere.muc.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1308147277-954804436=:401" Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-1308147277-954804436=:401 Content-Type: TEXT/PLAIN; charset=US-ASCII I think the following feature could be useful to module programmers, it adds the ability to list and unload kernel modules from within the debugger. Marc. --8323328-1308147277-954804436=:401 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="kdb.c.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="kdb.c.patch" KioqIGtkYi5jLm9yaWcJU2F0IE1hciAxOCAxMToyNzoxMyAyMDAwDQotLS0g a2RiLmMJU3VuIE1hciAxOSAwODowNzozNCAyMDAwDQoqKioqKioqKioqKioq KioNCioqKiAyNiwzMSAqKioqDQotLS0gMjYsMzggLS0tLQ0KICAjaW5jbHVk ZSAia2Ric3VwcG9ydC5oIg0KICAjaW5jbHVkZSAia2RiX2lvLmgiDQogIA0K KyAvKiBGb3Igcm1tb2QvbHNtb2QgKi8NCisgI2luY2x1ZGUgPGxpbnV4L21v ZHVsZS5oPg0KKyAjaW5jbHVkZSA8bGludXgvbW0uaD4NCisgI2luY2x1ZGUg PGFzbS9wZ3RhYmxlLmg+DQorIGV4dGVybiBzdHJ1Y3QgbW9kdWxlICptb2R1 bGVfbGlzdDsNCisgZXh0ZXJuIHZvaWQgdmZyZWUodm9pZCAqIGFkZHIpOw0K KyANCiAgdm9sYXRpbGUgaW50IGtkYl9hY3RpdmUgPSAwOw0KICB2b2xhdGls ZSBpbnQga2RiX2ZsYWdzID0gMDsNCiAgc3BpbmxvY2tfdCBrZGJfbG9jayA9 IFNQSU5fTE9DS19VTkxPQ0tFRDsNCioqKioqKioqKioqKioqKiBrZGIoaW50 IHJlYXNvbiwgaW50IGVycm9yLCBzdHJ1Y3QgcHRfcmVnDQoqKiogNzIzLDcy OSAqKioqDQogIAl9DQogIA0KICAJaWYgKHJlYXNvbiAhPSBLREJfUkVBU09O X0RFQlVHKSB7DQohIAkJa2RiX3ByaW50ZigiRW50ZXJpbmcga2RiICIpOw0K ICAjaWYgZGVmaW5lZChfX1NNUF9fKQ0KICAJCWtkYl9wcmludGYoIm9uIHBy b2Nlc3NvciAlZCAiLCBzbXBfcHJvY2Vzc29yX2lkKCkpOw0KICAjZW5kaWYN Ci0tLSA3MzAsNzM2IC0tLS0NCiAgCX0NCiAgDQogIAlpZiAocmVhc29uICE9 IEtEQl9SRUFTT05fREVCVUcpIHsNCiEgCQlrZGJfcHJpbnRmKCJcbkVudGVy aW5nIGtkYiAiKTsNCiAgI2lmIGRlZmluZWQoX19TTVBfXykNCiAgCQlrZGJf cHJpbnRmKCJvbiBwcm9jZXNzb3IgJWQgIiwgc21wX3Byb2Nlc3Nvcl9pZCgp KTsNCiAgI2VuZGlmDQoqKioqKioqKioqKioqKioga2RiKGludCByZWFzb24s IGludCBlcnJvciwgc3RydWN0IHB0X3JlZw0KKioqIDczNyw3NDMgKioqKg0K ICAJCSAqLw0KICAJCWRpYWcgPSBrZGJfZGJfdHJhcChyZWdzKTsNCiAgCQlp ZiAoZGlhZyA9PSAwKSB7DQohIAkJCWtkYl9wcmludGYoIkVudGVyaW5nIGtk YiAiKTsNCiAgI2lmIGRlZmluZWQoX19TTVBfXykNCiAgCQkJa2RiX3ByaW50 Zigib24gcHJvY2Vzc29yICVkICIsIHNtcF9wcm9jZXNzb3JfaWQoKSk7DQog ICNlbmRpZg0KLS0tIDc0NCw3NTAgLS0tLQ0KICAJCSAqLw0KICAJCWRpYWcg PSBrZGJfZGJfdHJhcChyZWdzKTsNCiAgCQlpZiAoZGlhZyA9PSAwKSB7DQoh IAkJCWtkYl9wcmludGYoIlxuRW50ZXJpbmcga2RiICIpOw0KICAjaWYgZGVm aW5lZChfX1NNUF9fKQ0KICAJCQlrZGJfcHJpbnRmKCJvbiBwcm9jZXNzb3Ig JWQgIiwgc21wX3Byb2Nlc3Nvcl9pZCgpKTsNCiAgI2VuZGlmDQoqKioqKioq KioqKioqKioga2RiX3JlYm9vdChpbnQgYXJnYywgY29uc3QgY2hhciAqKmFy Z3YsIA0KKioqIDEzODAsMTM4NSAqKioqDQotLS0gMTM4NywxNTgzIC0tLS0N CiAgCXJldHVybiAwOw0KICB9DQogIA0KKyANCisgLyoNCisgICogVGFrZW4g ZGlyZWN0bHkgZnJvbSBrZXJuZWwvbW9kdWxlLmMNCisgICoNCisgICogTG9v ayBmb3IgYSBtb2R1bGUgYnkgbmFtZSwgaWdub3JpbmcgbW9kdWxlcyBtYXJr ZWQgZm9yIGRlbGV0aW9uLg0KKyAgKi8NCisgc3RhdGljIHN0cnVjdCBtb2R1 bGUgKg0KKyBmaW5kX21vZHVsZShjb25zdCBjaGFyICpuYW1lKQ0KKyB7DQor ICAgICBzdHJ1Y3QgbW9kdWxlICptb2Q7DQorIA0KKyAgICAgZm9yIChtb2Qg PSBtb2R1bGVfbGlzdDsgbW9kIDsgbW9kID0gbW9kLT5uZXh0KSB7DQorICAg ICAgICAgaWYgKG1vZC0+ZmxhZ3MgJiBNT0RfREVMRVRFRCkNCisgICAgICAg ICAgICAgY29udGludWU7DQorICAgICAgICAgaWYgKCFzdHJjbXAobW9kLT5u YW1lLCBuYW1lKSkNCisgICAgICAgICAgICAgYnJlYWs7DQorICAgICB9DQor IA0KKyAgICAgcmV0dXJuIG1vZDsNCisgfQ0KKyANCisgLyoNCisgICogRnJl ZSB0aGUgZ2l2ZW4gbW9kdWxlLg0KKyAgKi8NCisgc3RhdGljIHZvaWQNCisg ZnJlZV9tb2R1bGUoc3RydWN0IG1vZHVsZSAqbW9kLCBpbnQgdGFnX2ZyZWVk KQ0KKyB7DQorIAlzdHJ1Y3QgbW9kdWxlX3JlZiAqZGVwOw0KKyAJdW5zaWdu ZWQgaTsNCisgI2lmIGRlZmluZWQoQ09ORklHX0tEQikNCisgCXN0cnVjdCBt b2R1bGVfc3ltYm9sICpzOw0KKyAjZW5kaWYNCisgDQorIAkvKiBMZXQgdGhl IG1vZHVsZSBjbGVhbiB1cC4gICovDQorIA0KKyAgCW1vZC0+ZmxhZ3MgfD0g TU9EX0RFTEVURUQ7DQorIAlpZiAobW9kLT5mbGFncyAmIE1PRF9SVU5OSU5H KQ0KKyAJew0KKyAJCWlmKG1vZC0+Y2xlYW51cCkNCisgCQkJbW9kLT5jbGVh bnVwKCk7DQorIAkJbW9kLT5mbGFncyAmPSB+TU9EX1JVTk5JTkc7DQorIAl9 DQorICNpZiBkZWZpbmVkKENPTkZJR19LREIpDQorIAkvKg0KKyAJKiBSZW1v dmUgc3ltYm9scyBmcm9tIGtlcm5lbCBkZWJ1Z2dlciANCisgCSovDQorIAlm b3IoaT0wLHM9bW9kLT5zeW1zOyBpPG1vZC0+bnN5bXM7IGkrKywgcysrKXsN CisgCQlrZGJkZWxtb2RzeW0ocy0+bmFtZSk7DQorIAl9DQorICNlbmRpZg0K KyANCisgCS8qIFJlbW92ZSB0aGUgbW9kdWxlIGZyb20gdGhlIGRlcGVuZGVu Y3kgbGlzdHMuICAqLw0KKyAJZm9yIChpID0gMCwgZGVwID0gbW9kLT5kZXBz OyBpIDwgbW9kLT5uZGVwczsgKytpLCArK2RlcCkgew0KKyAJCXN0cnVjdCBt b2R1bGVfcmVmICoqcHA7DQorIAlmb3IgKHBwID0gJmRlcC0+ZGVwLT5yZWZz OyAqcHAgIT0gZGVwOyBwcCA9ICYoKnBwKS0+bmV4dF9yZWYpDQorIAkJY29u dGludWU7DQorIAkqcHAgPSBkZXAtPm5leHRfcmVmOw0KKyAJaWYgKHRhZ19m cmVlZCAmJiBkZXAtPmRlcC0+cmVmcyA9PSBOVUxMKQ0KKyAJZGVwLT5kZXAt PmZsYWdzIHw9IE1PRF9KVVNUX0ZSRUVEOw0KKyAJfQ0KKyANCisgCS8qIEFu ZCBmcm9tIHRoZSBtYWluIG1vZHVsZSBsaXN0LiAgKi8NCisgCWlmIChtb2Qg PT0gbW9kdWxlX2xpc3QpIHsNCisgCQltb2R1bGVfbGlzdCA9IG1vZC0+bmV4 dDsNCisgCX0gZWxzZSB7DQorIAlzdHJ1Y3QgbW9kdWxlICpwOw0KKyAJZm9y IChwID0gbW9kdWxlX2xpc3Q7IHAtPm5leHQgIT0gbW9kOyBwID0gcC0+bmV4 dCkNCisgCQljb250aW51ZTsNCisgCXAtPm5leHQgPSBtb2QtPm5leHQ7DQor ICAgICAgIH0NCisgDQorIAkvKiBBbmQgZnJlZSB0aGUgbWVtb3J5LiAgKi8N CisgCW1vZHVsZV91bm1hcChtb2QpOw0KKyB9DQorIA0KKyAvKg0KKyAgKiBr ZGJfbHNtb2QNCisgICoNCisgICoJVGhpcyBmdW5jdGlvbiBpbXBsZW1lbnRz IHRoZSAnbHNtb2QnIGNvbW1hbmQuICBMaXN0cyBjdXJyZW50bHkgDQorICAq CWxvYWRlZCBrZXJuZWwgbW9kdWxlcy4NCisgICoNCisgICoJTW9zdGx5IHRh a2VuIGZyb20gdXNlcmxhbmQgbHNtb2QuDQorICAqDQorICAqIElucHV0czoN CisgICoJYXJnYwlhcmd1bWVudCBjb3VudA0KKyAgKglhcmd2CWFyZ3VtZW50 IHZlY3Rvcg0KKyAgKgllbnZwCWVudmlyb25tZW50IHZlY3Rvcg0KKyAgKgly ZWdzCXJlZ2lzdGVycyBhdCB0aW1lIGtkYiB3YXMgZW50ZXJlZC4NCisgICog T3V0cHV0czoNCisgICoJTm9uZS4NCisgICogUmV0dXJuczoNCisgICoJemVy byBmb3Igc3VjY2VzcywgYSBrZGIgZGlhZ25vc3RpYyBpZiBlcnJvcg0KKyAg KiBMb2NraW5nOg0KKyAgKglub25lLg0KKyAgKiBSZW1hcmtzOg0KKyAgKg0K KyAgKi8NCisgDQorIGludCANCisga2RiX2xzbW9kKGludCBhcmdjLCBjb25z dCBjaGFyICoqYXJndiwgY29uc3QgY2hhciAqKmVudnAsIHN0cnVjdCBwdF9y ZWdzICpyZWdzKQ0KKyB7DQorIAlzdHJ1Y3QgbW9kdWxlICptb2Q7DQorIAlz dHJ1Y3QgbW9kdWxlX3JlZiAqbXI7DQorIA0KKyAJaWYgKGFyZ2MgIT0gMCkN CisgCQlyZXR1cm4gS0RCX0FSR0NPVU5UOw0KKyANCisgCWtkYl9wcmludGYo Ik1vZHVsZSAgICAgICAgICAgICAgICAgIFNpemUgIFVzZWQgYnlcbiIpOw0K KyAJZm9yIChtb2QgPSBtb2R1bGVfbGlzdDsgbW9kICYmIG1vZC0+bmV4dCA7 bW9kID0gbW9kLT5uZXh0KSB7DQorIAkJa2RiX3ByaW50ZigiJS0yMHMlOGx1 JTRsZCAiLCBtb2QtPm5hbWUsIG1vZC0+c2l6ZSwgbW9kLT51Yy51c2Vjb3Vu dCk7DQorIA0KKyAJCWlmIChtb2QtPmZsYWdzICYgTU9EX0RFTEVURUQpIA0K KyAJCQlrZGJfcHJpbnRmKCIgKGRlbGV0ZWQpIik7DQorIAkJZWxzZSBpZiAo bW9kLT5mbGFncyAmIDY0KQ0KKyAJCQlrZGJfcHJpbnRmKCIgKGluaXRpYWxp emluZykiKTsNCisgCQllbHNlIGlmICghKG1vZC0+ZmxhZ3MgJiBNT0RfUlVO TklORykpDQorIAkJCWtkYl9wcmludGYoIiAodW5pbml0aWFsaXplZCkiKTsN CisgCQllbHNlIHsNCisgCQkJaWYgKG1vZC0+ZmxhZ3MgJiAgTU9EX0FVVE9D TEVBTikNCisgCQkJCWtkYl9wcmludGYoIiAoYXV0b2NsZWFuKSIpOw0KKyAJ CQlpZiAoIShtb2QtPmZsYWdzICYgTU9EX1VTRURfT05DRSkpDQorIAkJCQlr ZGJfcHJpbnRmKCIgKHVudXNlZCkiKTsNCisgCQl9DQorIAkJDQorIAkJaWYg KG1vZC0+cmVmcykgew0KKyAJCQlpbnQgaSA9IDA7DQorIA0KKyAJCQlrZGJf cHJpbnRmKCIgWyAiKTsNCisgDQorIAkJCW1yID0gbW9kLT5yZWZzOw0KKyAJ CQl3aGlsZSAobXIpIHsNCisgCQkJCWtkYl9wcmludGYoIiVzICIsIG1yLT5y ZWYtPm5hbWUpOwkNCisgCQkJCW1yID0gbXItPm5leHRfcmVmOw0KKyAJCQl9 CQ0KKyANCisgCQkJa2RiX3ByaW50ZigiXSIpOw0KKyAJCX0NCisgDQorIAkJ a2RiX3ByaW50ZigiXG4iKTsNCisgCX0NCisgDQorIAlyZXR1cm4gMDsNCisg fQ0KKyANCisgLyoNCisgICoga2RiX3JtbW9kDQorICAqDQorICAqCVRoaXMg ZnVuY3Rpb24gaW1wbGVtZW50cyB0aGUgJ3JtbW9kJyBjb21tYW5kLiAgUmVt b3ZlcyBhIGdpdmVuICANCisgICoJa2VybmVsIG1vZHVsZS4NCisgICoNCisg ICogSW5wdXRzOg0KKyAgKglhcmdjCWFyZ3VtZW50IGNvdW50DQorICAqCWFy Z3YJYXJndW1lbnQgdmVjdG9yDQorICAqCWVudnAJZW52aXJvbm1lbnQgdmVj dG9yDQorICAqCXJlZ3MJcmVnaXN0ZXJzIGF0IHRpbWUga2RiIHdhcyBlbnRl cmVkLg0KKyAgKiBPdXRwdXRzOg0KKyAgKglOb25lLg0KKyAgKiBSZXR1cm5z Og0KKyAgKgl6ZXJvIGZvciBzdWNjZXNzLCBhIGtkYiBkaWFnbm9zdGljIGlm IGVycm9yDQorICAqIExvY2tpbmc6DQorICAqCW5vbmUuDQorICAqIFJlbWFy a3M6DQorICAqDQorICAqLw0KKyANCisgaW50IA0KKyBrZGJfcm1tb2QoaW50 IGFyZ2MsIGNvbnN0IGNoYXIgKiphcmd2LCBjb25zdCBjaGFyICoqZW52cCwg c3RydWN0IHB0X3JlZ3MgKnJlZ3MpDQorIHsNCisgCXN0cnVjdCBtb2R1bGUg Km1vZDsNCisgCQ0KKyANCisgCWlmIChhcmdjICE9IDEpDQorIAkJcmV0dXJu IEtEQl9BUkdDT1VOVDsNCisgDQorIAlrZGJfcHJpbnRmKCJBdHRlbXB0aW5n IHRvIHJlbW92ZSBtb2R1bGU6IFslc11cbiIsIGFyZ3ZbMV0pOw0KKyAJaWYg KChtb2QgPSBmaW5kX21vZHVsZShhcmd2WzFdKSkgPT0gTlVMTCkgew0KKyAJ CWtkYl9wcmludGYoIlVuYWJsZSB0byBmaW5kIGEgbW9kdWxlIGJ5IHRoYXQg bmFtZVxuIik7DQorIAkJcmV0dXJuIDA7DQorIAl9DQorIA0KKyAJaWYgKG1v ZC0+cmVmcyAhPSBOVUxMIHx8IF9fTU9EX0lOX1VTRShtb2QpKSB7DQorIAkJ a2RiX3ByaW50ZigiTW9kdWxlIGlzIGluIHVzZSwgdW5hYmxlIHRvIHVubG9h ZFxuIik7DQorIAkJcmV0dXJuIDA7DQorIAl9DQorIA0KKyAJZnJlZV9tb2R1 bGUobW9kLCAwKTsNCisgCWtkYl9wcmludGYoIk1vZHVsZSBzdWNjZXNzZnVs bHkgdW5sb2FkZWRcbiIpOw0KKyANCisgCXJldHVybiAwOw0KKyB9DQorIA0K ICAvKg0KICAgKiBrZGJfZW52DQogICAqDQoqKioqKioqKioqKioqKioga2Ri X2luaXR0YWIodm9pZCkNCioqKiAxODU2LDE4NjEgKioqKg0KLS0tIDIwNTQs MjA2MSAtLS0tDQogICNlbmRpZgkvKiBfX1NNUF9fICovDQogIAlrZGJfcmVn aXN0ZXIoInBzIiwga2RiX3BzLCAiIiwgCQkiRGlzcGxheSBhY3RpdmUgdGFz ayBsaXN0IiwgMCk7DQogIAlrZGJfcmVnaXN0ZXIoInJlYm9vdCIsIGtkYl9y ZWJvb3QsICIiLCAgIlJlYm9vdCB0aGUgbWFjaGluZSBpbW1lZGlhdGVseSIs IDApOw0KKyAJa2RiX3JlZ2lzdGVyKCJsc21vZCIsIGtkYl9sc21vZCwgIiIs CSJMaXN0IGxvYWRlZCBrZXJuZWwgbW9kdWxlcyIsIDApOw0KKyAJa2RiX3Jl Z2lzdGVyKCJybW1vZCIsIGtkYl9ybW1vZCwgIjxtb2RuYW1lPiIsICJSZW1v dmUgZ2l2ZW4ga2VybmVsIG1vZHVsZSIsIDEpOw0KICAjaWYgZGVmaW5lZChD T05GSUdfTUFHSUNfU1lTUlEpDQogIAlrZGJfcmVnaXN0ZXIoInNyIiwga2Ri X3NyLCAiPGtleT4iLAkiTWFnaWMgU3lzUnEga2V5IiwgMCk7DQogICNlbmRp Zg0K --8323328-1308147277-954804436=:401-- From owner-kdb@oss.sgi.com Wed Apr 19 14:43:25 2000 Received: by oss.sgi.com id ; Wed, 19 Apr 2000 14:43:15 -0700 Received: from baucis.sc.intel.com ([143.183.152.22]:16655 "EHLO baucis.sc.intel.com") by oss.sgi.com with ESMTP id ; Wed, 19 Apr 2000 14:42:50 -0700 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.22 2000/04/06 17:58:51 dmccart Exp $) with SMTP id OAA10175 for ; Wed, 19 Apr 2000 14:42:44 -0700 (PDT) Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 19 Apr 2000 21:42:44 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id <2XNHRRX1>; Wed, 19 Apr 2000 14:42:43 -0700 Message-ID: From: "Dunlap, Randy" To: "'kdb@oss.sgi.com'" Subject: kdb problems Date: Wed, 19 Apr 2000 14:42:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing Hi, I'm using kdb-v1.1-2.3.48 on 2.3.99-pre6-3 (with a couple minor changes only to linux/Makefile, include/asm-386/apicdef.h, and arch/i386/kernel/smp.c). a. Just to let you know, "go" still isn't fixed on some platforms. (From the FAQ: Note: This may be fixed in v0.6 - please let me know if it isn't.) b. When I use the "bt" command, I get a screen full on the same line replicated to fill up the screen (until [more] is printed). After pressing Enter/CR, I get the SAME bt output. It appears to be broken. CONFIG_KDB_FRAMEPTR=y. ~Randy ___________________________________________________ |Randy Dunlap Intel Corp., DAL Sr. SW Engr.| |randy.dunlap.at.intel.com 503-696-2055| |NOTE: Any views presented here are mine alone | |and may not represent the views of my employer. | |_________________________________________________| From owner-kdb@oss.sgi.com Wed Apr 19 16:06:45 2000 Received: by oss.sgi.com id ; Wed, 19 Apr 2000 16:06:35 -0700 Received: from ganymede.or.intel.com ([134.134.248.3]:47623 "EHLO ganymede.or.intel.com") by oss.sgi.com with ESMTP id ; Wed, 19 Apr 2000 16:06:14 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.22 2000/04/06 17:58:51 dmccart Exp $) with SMTP id QAA26900 for ; Wed, 19 Apr 2000 16:06:14 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 19 Apr 2000 23:06:13 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id <27735QRA>; Wed, 19 Apr 2000 16:06:12 -0700 Message-ID: From: "Dunlap, Randy" To: "'kdb@oss.sgi.com'" Subject: RE: kdb problems Date: Wed, 19 Apr 2000 16:06:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing Hi, Some followup.. (In other words, I could have something besides kdb problems.) I have an app that does an ioctl to a driver. I'm getting an Oops and using kdb to debug it. With kdb, I'm seeing esp = 0xd0823bcd [odd number] and eip = 0xd08238b0 [near esp]. ebp = 0xc04e7e44. I expected esp to be near ebp, not near eip (?). Is it uncommon/wrong/strange for esp to be an odd value? Is it unusual for esp to be near eip? I expected it to be near ebp, not eip. So it looks to me like esp is scrogged -- unless kdb modifies it in some strange/funny way (?). If I dump memory at ®s (from the regs display), I can see these same values of esp and eip in the regs memory area (but didn't check their offsets). Also, regarding the BT command in kdb, if BT may have difficulty in following stack frames, maybe a limit should be put on how many traceback lines (frames) it will follow. I printed the same one a few hundred times before I rebooted my system. ~Randy > -----Original Message----- > From: Dunlap, Randy > Sent: Wednesday, April 19, 2000 2:43 PM > To: 'kdb@oss.sgi.com' > Subject: kdb problems > > > Hi, > > I'm using kdb-v1.1-2.3.48 on 2.3.99-pre6-3 (with a > couple minor changes only to linux/Makefile, > include/asm-386/apicdef.h, and arch/i386/kernel/smp.c). > > a. Just to let you know, "go" still isn't fixed on > some platforms. (From the FAQ: > > Note: This may be fixed in v0.6 - please let me > know if it isn't.) > > b. When I use the "bt" command, I get a screen full > on the same line replicated to fill up the screen > (until [more] is printed). After pressing Enter/CR, > I get the SAME bt output. It appears to be broken. > CONFIG_KDB_FRAMEPTR=y. > > ~Randy From owner-kdb@oss.sgi.com Wed Apr 19 16:45:15 2000 Received: by oss.sgi.com id ; Wed, 19 Apr 2000 16:44:56 -0700 Received: from tourguide.nanobiz.com ([208.176.9.173]:16376 "EHLO pendragon.eng.nanobiz.com") by oss.sgi.com with ESMTP id ; Wed, 19 Apr 2000 16:44:27 -0700 Received: (from slurn@localhost) by pendragon.eng.nanobiz.com (8.9.3/8.9.3) id QAA00894; Wed, 19 Apr 2000 16:42:22 -0700 From: Scott Lurndal Message-Id: <200004192342.QAA00894@pendragon.eng.nanobiz.com> Subject: Re: kdb problems To: randy.dunlap@intel.com (Dunlap, Randy) Date: Wed, 19 Apr 2000 16:42:22 -0700 (PDT) Cc: kdb@oss.sgi.com ('kdb@oss.sgi.com') In-Reply-To: from "Dunlap, Randy" at Apr 19, 2000 04:06:11 PM 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, > > Some followup.. (In other words, > I could have something besides kdb problems.) > > I have an app that does an ioctl to a driver. > I'm getting an Oops and using kdb to debug it. > > With kdb, I'm seeing esp = 0xd0823bcd [odd number] > and eip = 0xd08238b0 [near esp]. ebp = 0xc04e7e44. > I expected esp to be near ebp, not near eip (?). esp should _always_ be congruent to zero modulo 16 - this is required so all pushes of multiword data are aligned correctly (e.g. floating stuff). > > Is it uncommon/wrong/strange for esp to be an odd value? Very strange. > Is it unusual for esp to be near eip? I expected it to > be near ebp, not eip. I suspect that someone dereferenced a uninitialized function pointer that had a stack address in it. > So it looks to me like esp is scrogged -- unless kdb > modifies it in some strange/funny way (?). Nope. > > If I dump memory at ®s (from the regs display), > I can see these same values of esp and eip in the > regs memory area (but didn't check their offsets). ®s is basically the stack pointer immediately following the processor pushing the processor state after a fault or interrupt. > > > Also, regarding the BT command in kdb, if BT may have > difficulty in following stack frames, maybe a limit > should be put on how many traceback lines (frames) > it will follow. I printed the same one a few hundred > times before I rebooted my system. It should hit the 'more>' code and you can use 'q' to exit. scott > > ~Randy > > > > -----Original Message----- > > From: Dunlap, Randy > > Sent: Wednesday, April 19, 2000 2:43 PM > > To: 'kdb@oss.sgi.com' > > Subject: kdb problems > > > > > > Hi, > > > > I'm using kdb-v1.1-2.3.48 on 2.3.99-pre6-3 (with a > > couple minor changes only to linux/Makefile, > > include/asm-386/apicdef.h, and arch/i386/kernel/smp.c). > > > > a. Just to let you know, "go" still isn't fixed on > > some platforms. (From the FAQ: > > > > Note: This may be fixed in v0.6 - please let me > > know if it isn't.) > > > > b. When I use the "bt" command, I get a screen full > > on the same line replicated to fill up the screen > > (until [more] is printed). After pressing Enter/CR, > > I get the SAME bt output. It appears to be broken. > > CONFIG_KDB_FRAMEPTR=y. > > > > ~Randy > From owner-kdb@oss.sgi.com Sat Apr 22 05:54:08 2000 Received: by oss.sgi.com id ; Sat, 22 Apr 2000 05:53:59 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:44815 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Sat, 22 Apr 2000 05:53:38 -0700 Received: (qmail 29095 invoked by uid 502); 22 Apr 2000 12:53:32 -0000 Received: (qmail 29088 invoked from network); 22 Apr 2000 12:53:31 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Apr 2000 12:53:31 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: kdb@oss.sgi.com Subject: An alternative source of kernel symbols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Apr 2000 22:53:30 +1000 Message-ID: <30837.956408010@ocs3.ocs-net> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing modutils 2.3.11 provides generic support for debuggers by loading a complete set of non-stack symbols in the kernel and in modules. This is activated when the kernel is compiled with CONFIG_KALLSYMS[1]. As proof of concept, I reworked kdb v0.6 against kernel 2.2.15pre19 and kdb v1.0 against kernel 2.3.99-pre6-5 to use kallsyms instead of kdb's own method of obtaining symbols. Loading a complete non-stack symbol table is relatively expensive, it adds 10-20% to the size of the kernel and modules. The CONFIG_KALLSYMS option should only be used when debugging. The kallsyms data contains a lot of data, for the kernel and for each module it lists * The section names, start and end addresses. * The symbol names, start and end addresses and the section each symbol belongs to. Why this much data? Because if you have the start address of the section and the start and end of a symbol, you can get a clean disassemble of a module with addresses that match your system by objdump -S -j --adjust-vma= \ --start-address= --stop-address= \ module.o A similar command for the kernel, omit --adjust-vma because the kernel is executable, not relocatable. objdump -S -j \ --start-address= --stop-address= \ vmlinux -S disassembles the section. If you compiled the kernel with -g you even get source and binary interleaved in the objdump listing. As proof of concept for kallsyms, modutils/v2.3 contains patch-2.2.15pre19-kallsyms.gz Add CONFIG_KALLSYMS to kernel 2.2.15pre19. patch-2.2.15pre19-kallsyms-kdb-v0.6.gz Add CONFIG_KALLSYMS + reworked SGI kdb v0.6 against kernel 2.2.15pre19. patch-2.3-99-pre6-5-kallsyms.bz2 Add CONFIG_KALLSYMS to kernel 2.3-99-pre6-5. patch-2.3-99-pre6-5-kallsyms-kdb-v1.0.bz2 Add CONFIG_KALLSYMS + reworked SGI kdb v1.0 against kernel 2.3-99-pre6-5. * It uses kallsyms for its symbol table instead of the SGI symbol table. * No fixed size for the symbol table and no need to ask the user for a size at compile time. * Using the section data accurately verifies that an address falls within a kernel or module section instead of using the less reliable test on _[se]text and vmalloc areas. * Every symbol printed is followed by the module name, the section start, the symbol start and end addresses. Feed these addresses into objdump -S for a nice disassemble. [1] CONFIG_KALLSYMS is not yet integrated into the kernel, whether it will be integrated depends on its usage. If nobody uses it then I cannot persuade Linus to include it. From owner-kdb@oss.sgi.com Sat Apr 22 06:00:58 2000 Received: by oss.sgi.com id ; Sat, 22 Apr 2000 06:00:48 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:45839 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Sat, 22 Apr 2000 06:00:41 -0700 Received: (qmail 29154 invoked by uid 502); 22 Apr 2000 13:00:36 -0000 Received: (qmail 29147 invoked from network); 22 Apr 2000 13:00:35 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Apr 2000 13:00:35 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: kdb@oss.sgi.com Subject: Re: An alternative source of kernel symbols In-reply-to: Your message of "Sat, 22 Apr 2000 22:53:30 +1000." <30837.956408010@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Apr 2000 23:00:34 +1000 Message-ID: <30896.956408434@ocs3.ocs-net> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing On Sat, 22 Apr 2000 22:53:30 +1000, Keith Owens wrote: >As proof of concept for kallsyms, modutils/v2.3 contains Forgot to include the URLs. Mirror at ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3 Mirror at ftp://oss.sgi.com/pub/mirror/modutils/v2.3 Master at ftp://ftp.ocs.com.au/pub/modutils/v2.3 (slow) From owner-kdb@oss.sgi.com Thu Apr 27 15:34:25 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 15:34:14 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:1800 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 27 Apr 2000 15:34:08 -0700 Received: (qmail 4160 invoked by uid 502); 27 Apr 2000 22:34:03 -0000 Received: (qmail 4149 invoked from network); 27 Apr 2000 22:34:01 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 27 Apr 2000 22:34:01 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: kdb@oss.sgi.com Subject: CVS for kdb? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Apr 2000 08:34:00 +1000 Message-ID: <5299.956874840@ocs3.ocs-net> Sender: owner-kdb@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;kdb-outgoing A recent mail from Andi Kleen implies that kdb is available via CVS. Where is it? I can find no mention of CVS on any of the oss.sgi.com pages, the lack of a search facility on that site does not help. From owner-kdb@oss.sgi.com Thu Apr 27 16:34:15 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 16:34:05 -0700 Received: from host196.creativedesign.com ([207.135.94.196]:58118 "HELO host196.creativedesign.com") by oss.sgi.com with SMTP id ; Thu, 27 Apr 2000 16:33:49 -0700 Received: from eventdriven.org (IDENT:root@localhost.localdomain [127.0.0.1]) by host196.creativedesign.com (8.9.3/8.9.3) with ESMTP id QAA04897; Thu, 27 Apr 2000 16:33:28 -0700 Message-ID: <3908CE47.7FE08626@eventdriven.org> Date: Thu, 27 Apr 2000 16:33:27 -0700 From: Kip Matthew Macy X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.3.99-pre2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: kdb@oss.sgi.com Subject: Re: CVS for kdb? References: <5299.956874840@ocs3.ocs-net> 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 Keith Owens wrote: > A recent mail from Andi Kleen implies that kdb is available via CVS. > Where is it? I can find no mention of CVS on any of the oss.sgi.com > pages, the lack of a search facility on that site does not help. If you just want kernel source with kdb in it you can CVS checkout the xfs tree. -Kip