From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Duperval To: GDB Mailing List Subject: Re: Breaking outside of the sources Date: Tue, 24 Apr 2001 13:39:00 -0000 Message-id: <20010424211635.469D7469AF@lenard.microcelli5.com> References: X-SW-Source: 2001-04/msg00184.html 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 >