I was hoping I could put this thread to rest, but I'm encountered one more issue with the combination of kernel debugging and the new config file for 2.6.22 that I think everyone would like to know. In particular, I'm had a problem viewing the kernel's call stack using after using the .config file that Ali sent me. The specific error is below. I noticed this error only existed with my new build of 2.6.22 and realized that the CONFIG_PRINTK_TIME=y and CONFIG_ENABLE_MUST_CHECK=y should be set in .config to enable kernel call stack traces. You may want to update your .config file accordingly.
Brad (gdb) c Continuing. Program received signal SIGILL, Illegal instruction. 0xfffffc0000010134 in ?? () (gdb) bt #0 0xfffffc0000010134 in ?? () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0xfffffc0000010134 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. #1 0xfffffc0000013780 in ?? () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0xfffffc0000013780 Previous frame identical to this frame (corrupt stack?) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ali Saidi Sent: Tuesday, June 03, 2008 3:25 PM To: M5 users mailing list Subject: Re: [m5-users] Config File for Linux 2.6.22 We encourage editing... please add anything that you think is missing or needs clarification. Thanks, Ali On Jun 3, 2008, at 6:20 PM, Beckmann, Brad wrote: > Thanks Nate! > > I noticed someone just updated the wiki. I added a bit more detail > concerning multiple processor kernel debugging. I hope you don't > mind. > > Brad > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On > Behalf Of nathan binkert > Sent: Tuesday, June 03, 2008 11:46 AM > To: M5 users mailing list > Subject: Re: [m5-users] Config File for Linux 2.6.22 > > You should set the current_debugger variable from gdb manually. This > is so the correct CPU gets stopped. We should probably add a method > to the cpu object called debugger so this can be done a bit more > easily, but currently, you need to figure out the cpu, set > current_debugger, then call debugger() > > Nate > > On Tue, Jun 3, 2008 at 11:17 AM, Beckmann, Brad > <[EMAIL PROTECTED]> > wrote: >> Thanks Ali, that was it! >> >> As I suspected, my .config file attempts where way off from what they >> should have been. The .config file you sent me appears to be working >> great so far. >> >> Also, thanks for letting me know that the debugger function is >> 'debugger()' not 'Debugger()'. Unfortunately, I'm still encountering >> problems when calling the kernel debugger from the user-level >> debugger >> on M5. So the calls to 'debugger()' don't encounter a symbol not > found >> error, but they don't break into the kernel debugger either. >> Instead, >> nothing seems to happen. Actually after examining the function >> debugger() in src/base/remote_gdb.cc, I'm not sure how the gdb is >> ever >> called. It appears the current_debugger static int is set to -1 and >> there is no possibility to set the current_debugger variable to a >> different value. Thus the debugger loop is not executed and the > kernel >> gdb session is never called. Is my understanding correct, or does > some >> external object change the value of current_debugger? Below is the >> specific code I'm referring to. >> >> Thanks again for all your help. I really appreciate it. >> >> Brad >> >> >> >> >> void >> debugger() >> { >> static int current_debugger = -1; >> if (current_debugger >= 0 && current_debugger < debuggers.size()) { >> BaseRemoteGDB *gdb = debuggers[current_debugger]; >> if (!gdb->isattached()) { >> gdb->listener->accept(); >> } >> if (gdb->isattached()) { >> gdb->trap(SIGILL); >> } >> } >> } >> >> -----Original Message----- >> From: Ali Saidi [mailto:[EMAIL PROTECTED] >> Sent: Monday, June 02, 2008 6:29 PM >> To: Beckmann, Brad >> Subject: Re: [m5-users] Config File for Linux 2.6.22 >> >> >> On Jun 2, 2008, at 8:16 PM, Beckmann, Brad wrote: >> >>> Hi Ali, >>> >>> I've been having problems creating a build of Linux 2.6.22 that >>> matches with the supported Tsunami platform in M5. I think the > source >> >>> of problems is incorrectly configuring the VGA device and I want to > go >> >>> back to the configuration question (see below) that I asked a few >>> weeks ago. >>> I noticed that the M5 patches make changes to the following files: >>> arch/alpha/Kconfig, arch/alpha/kernel/console.c, and >>> arch/alpha/kernel/proto.h. In particular, these changes appear to >>> allow the DUMMY_CONSOLE to be built without the VGA_HOSE being >>> defined. To avoid the define dependencies on VGA_HOSE, the changes >>> also switch some "#ifdef CONFIG_VGA_HOSE" lines to "#ifdef >>> CONFIG_VGA_HOSE1". Is my understanding correct? >> Yea, some dependence was introduced in the 2.6.22 kernel that I >> really >> haven't looked at, but that required a VGA adapter to be added to >> configuration. Since we don't even support probing of the VGA device, >> that had to be removed. >> >>> >>> The problem with these changes is they appear incomplete without the >>> necessary changes to the config files. Specifically, I assume one >>> needs to remove the dependency between VGA_HOSE and ALPHA_GENERIC in >>> Kconfig. >>> Therefore, CONFIG_DUMMY_CONSOLE, CONFIG_ALPHA_GENERIC, and >>> CONFIG_ALPHA_LEGACY_START_ADDRESS are defined, while >>> CONFIG_VGA_CONSOLE, CONFIG_VGA_HOSE, and CONFIG_VGA_HOSE1 are not >>> defined. The result is the kernel builds with empty implementations >>> of the >>> find_console_vga_hose() and locate_and_init_vga() functions. Is my >>> configuration assumption correct? >> Well, all you need to do is not enable any VGA adapters in your >> kernel >> configuration file and there isn't a problem. >> >>> >>> >>> So with the above configuration, I encounter a M5 assertion check > that >>> appears to be caused by an incorrectly "faked" device. In > particular, >>> the following trace indicates the faulting address is 0x801fc0001ef >>> which maps in between the fake_ata0 and fake_ata1 devices. I have a >>> sucpicion that this error is caused by the vga device not really > being >>> removed, but I'm not sure. What is your opinion? >>> >>> 1942464295500: testsys.membus: recvAtomic: packet src 3 dest -1 addr >>> 0x801fc0001ef cmd ReadReq >>> 1942464295500: testsys.membus: Unable to find destination for addr: >>> 0x801fc0001ef, will use default port >>> 1942464295500: testsys.membus.responder: Device >>> testsys.membus.responder >>> read to bad address va=0x801fc0001ef size=1 >> The VGA device has a BadDevice where it is, I don't know why you're >> seeing that. >> >>> >>> Finally, I wanted to get a stack trace of the kernel when this error >>> occurs, but I'm having a problem calling the Linux kernel debugger >>> from >>> the user-level debugger on M5. The website >>> (http://www.m5sim.org/wiki/index.php/Debugging_M5) indicates the >>> kernel >>> debugger can be called by a 'call Debugger()' command, but I think >>> that >>> is assuming the Debugger() function is defined? Who defines the >>> Debugger function, because I receive a 'No symbol "Debugger" in >>> current >>> context.' Error when I try to call the Debugger function from the M5 >>> debugger. >> >> The case on the webpage is wrong, it should be debugger(). The >> function is defined in remote_gdb.cc although you would need to >> schedule a break cycle (schedBreakCycle() from within the gdb >> instance >> that is debugging m5 would work), before you hit that error. >> >> I've attached a linux 2.6.22 config file I just created. It builds >> and >> successfully boots to the bash prompt. >> >> Ali >> >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >> >> > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
