Hi, Sorry for the late reply.
On Wed, Jul 17, 2013 at 1:25 AM, Luis Machado <lgust...@codesourcery.com>wrote: > Hi, > > > On 07/16/2013 02:04 PM, Yue Lu wrote: > >> Hi, >> >> thanks for you reply. >> >> On Wed, Jul 17, 2013 at 12:44 AM, Luis Machado >> >>> Some general thoughts... >>> >>> >>> Can you make sure the breakpoint has been lifted from the instruction it >>> replaced? If the breakpoint has been lifted and it is still being hit, >>> then >>> it sounds like there is some kind of instruction cache problem going on, >>> where we first need to flush the icache before resuming execution. >>> >>> If the icache is the problem, then it sounds like something the kernel >>> itself needs to address. >>> >>> Luis >>> >> >> I don't know how to flush the icache off-hand, so I used anther way to >> bypass this issue. I set the eip to the next instruction's address to >> bypass the breakpoint ins. But problem seems doesn't go away. >> > > I don't think the cache invalidation is something the debugger should do. > Sounds like something the kernel would do. > > When you set the EIP to some other instruction (not the breakpoint one), > what do you see when you instruction-step? What does the EIP show after > that? > > Luis > I don't have do the instruction-step, because I don't know how to step it. Is it must step after continue the inferior at breakpoint? When I get the exception message, I set the EIP to the next instruction (for instance 0x12345678), after resume it, I call get_thread_state(), and found the EIP is still 0x12345678. The inferior never running anymore. -- Yue Lu (陆岳)
