From mboxrd@z Thu Jan 1 00:00:00 1970 From: Denset.Serralta@radisys.com To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: GDB does not step into or over "sleep" function Date: Fri, 01 Dec 2000 11:55:00 -0000 Message-id: X-SW-Source: 2000-12/msg00004.html Jim Blandy cc: gdb@sources.redhat.com Sent by: Subject: Re: GDB does not step into or over "sleep" function gdb-owner@sources. redhat.com 11/28/00 08:07 PM Jim Blandy wrote: >Let me make sure I understand. If you have code like this: > > ... some code ... > ProcessSleep (...); > ... some more code ... > >and you set a breakpoint on the `some more code' line, your program >hangs and never reaches the breakpoint. >But if you run the program without GDB, it sleeps the expected amount >of time, and then continues normally. Thanks for responding You are correct. The breakpoint in "...some more code ..." is never reached. We are suspecting at the moment that it is a problem with the ProcessSleep function since the hang occurrs when we 'step into' or 'step over' it. What we don't know is whether it is a problem with our underlying kernel functions or whether GDB has a problem with a "sleep" function which allocates a semaphore, blocks on it subject to a user specified timeout and then returns the semaphore. We are leaning to suspecting that it is a problem with our custom kernel (i.e. GDB is innocent). However I thought I would ask the GDB group, with all the combined experience developing GDB, just in case they saw something obvious. Thanks again Denset.Serralta@radisys.com >Denset.Serralta@radisys.com writes: >> We are using GDB 4.18 on an NT host to debug target software running on a >> PowerPC based adapter. We are using a function called ProcessSleep which is >> a call to our kernel. It basically allocates a semaphore, blocks on it >> subject to a user specified timeout and then returns the semaphore.One >> problem we can't seem to get around though is that if the process being >> debugged makes a 'ProcessSleep' call, the debugger never gains control when >> we step over it. Even if we set a breakpoint past the call and let it run, >> it never returns. A status utility that we have shows the process as >> queued, but we never regain control. Does anybody know any reason(s) why >> this should happen.