Re: Breaking outside of the sources

[Laurent Duperval <lduperval at microcelli5 dot com>]

On 24 Apr, Keith Seitz wrote:
> On Tue, 24 Apr 2001, Laurent Duperval wrote:
> 
>> Someone sent an email on the insight list complaining that when gdb is
>> interrupted, you can find yourself stuck in assembly in a line of
>> /lib/libc.so instead of a line from your program. He asked whether it was
>> possible to limit the lines seen to the programs being debugged and not to
>> see system library stuff. I thought it was a a legitimate question.
> 
> If you interrupt a system call (you were blocked in select, poll, read, 
> write, etc), then gdb dutifully prints out that you are there, because 
> your program IS there. It is not somewhere else, it is in the system 
> call, executing code in a (possibly shared) system library.
> 

Right.

> Of course, I could misunderstand this question entirely. It sounds like 
> the user is requesting that the debugger lie to him about what his 
> program is executing...
> 

Not really. Often, breaking in system libraries doesn't provide interesting
feedback. If I interrupt the program, most of the time I'm not interested in
knowing that I was in poll(), select() or other sytem calls. But I am
interested in knowing in which part of my code the poll(), select()... was
called. Most of the time it can be done using the stacktrace but for new
users (especially) it adds an unwanted (unneeded?) level of complexity.

I think (I dunno, I haven't used them in a while) that's the way MS
debuggers work.

L

-- 
Laurent Duperval <mailto:lduperval@microcelli5.com>