On 07/04/11 23:17, Nilay wrote: > On Tue, July 5, 2011 12:11 am, Mahmood Naderan wrote: >> Why debugging with gdb is so hard in gem5? >> >> I have worked with some other programs that are more gdb friendly than >> gem5. For example, in Flexus, if -gdb is passed to the command line, a >> PID is given to the user so that he can attach gdb to that PID. Then >> when ever a segmentation fault occurs, the gdb catches the signal and >> the user can view the backtrace. It is easy to find whcih function >> caused that fault (for example pointer and array faults). >> >> I got a seg fault and till now I have not located where in the code, >> the fault occurs. I have read the documentation about debugging. >> Tracing the assembly code is not suitable for my case. >> > I am surprised at the statement that gem5 is not gdb friendly. Figuring > out where the segmentation fault occurred using gdb, as per my experience, > is straight forward and is independent of what program in under > consideration. Compile gem5.debug and run it under gdb, the program will > stop execution where ever segmentation fault occurs. Then you can view the > stack of the functions that have been called. I suggest that you read the > documentation on how a any program is run under gdb. > > -- > Nilay > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
The segfault is in the simulated program, not in gem5 itself. If something else works better for you, you're welcome to use it. Gabe _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
