Hi Samuel, It's because of virtual vs physical addresses. When the kernel starts it is operating on physical addresses and all the symbols were read in have virtual addresses. You could hack the code to set a breakpoint on a physical address or just set break points by address instead of symbols.
Ali Sent from my ARM powered mobile device On Mar 12, 2012, at 3:18 AM, Samuel Hitz <[email protected]> wrote: > Hi there, > > I'm trying to debug my kernel from the beginning in Gem5. I set a breakpoint > in the 'start' method. When I start gem5 it waits for a remote gdb to attach > and then I can follow the bootloader code, but as soon as the jump to the > kernel arrives, I'm no longer able to follow the code and it doesn't break at > the start method. > This happens also when I try to debug the sample ARM linux kernel. I can't > break in 'stext' (the entry point of the kernel) but I can eg. break in > 'printk'. Is there something special I have to do, to be able to debug the > kernel from the start, like providing a separate symbol/relocation table to > gdb? > > Best, > > Samuel > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
