From mboxrd@z Thu Jan  1 00:00:00 1970
From: pmcgarry <pmcgarry@hekimian.com>
To: Laurent Duperval <lduperval@microcelli5.com>, GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: RE: Breaking outside of the sources
Date: Tue, 24 Apr 2001 14:14:00 -0000
Message-id: <5DC9745D8405D4119BD700606D1D7472021A6313@thor.hekimian.com>
X-SW-Source: 2001-04/msg00186.html

> -----Original Message-----
> From: Laurent Duperval [ mailto:lduperval@microcelli5.com ]
> Sent: Tuesday, April 24, 2001 4:22 PM
> To: GDB Mailing List
> Subject: Re: Breaking outside of the sources
> 
> 
> 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.

Actually, the MS VC++ integrated debugger (and all other good debuggers that
I know of) actually break in the system call if that is where you are!  So
it doesn't surprise me at all that gdb would do the same thing - it is the
'right' thing to do.

The reasons are actually quite simple, and the two most important are that
1) that's what most good engineers want anyway, and 2) you want to know
exactly what the code is/was doing when it broke.  

It really should not be considered an added level of complexity; in fact, it
helps you to determine what the nature of your problem actually is.  

For example, if you end up with memory access violations, etc., and they
appear to be occuring in system code, then chances are you have corrupted
pointer data or have overwritten memory, and then you can start focusing on
investigating the calling chain to determine just what caused the bubble to
burst.

Another good example is when you end up with the (n)ever-popular
sprintf/printf problems where parameters don't match up correctly.  Noting
failures in resultant system calls can often point you right to such a
problem.

You can often times get an idea of what caused the problem by investigating
the register sets at the particular point of failure in the system call.
Perhaps you will be lucky enough to note that one of the values looks like
an address, and dereferencing such an address seems to show you some data
that correlates to a routine that you recently changed.  This 'luckiness'
can happen more often than you might think.  :)

Most of these situations can of course be handled via the stack trace or any
other similar mechanism you may have available in your particular debugger -
I am not a consistent user of gdb, so I can't speak as to the facilities
there but I'm sure others on this list can.  From the stack trace, you
should be able to select any of the methods/functions in the calling chain
and investigate the local scope for the individual pieces of code that led
up to the problem itself, which just happened to finally materialize in the
system call.

Finally, remember that some notoriously-difficult-to-debug problems take
time and effort for even expert programmers and expert debuggers to figure
out.  You just have to be ready and willing to fight the good fight!

Pat