Bug 92309 - CDT Debug Step issue
Summary: CDT Debug Step issue
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Developer Suite
Classification: Retired
Component: eclipse
Version: 1.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Keith Seitz
QA Contact: eclipse-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-06-04 19:21 UTC by Phil Muldoon
Modified: 2007-04-18 16:54 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-06-11 20:31:25 UTC
Embargoed:


Attachments (Terms of Use)

Description Phil Muldoon 2003-06-04 19:21:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
in the CDT (using C++), while debugging, i for some reason cannot use
the stepping through function (to go through the code line by line).

it hangs on the first "std::cout <<" line.

stepping through works for C code.

also, stepping through works with the same code on another machine
running Red Hat 9 (i have Red Hat 8.0) but failed on another machine
running RH 8

is this an OS problem?

Thanks - Bertina

Version-Release number of selected component (if applicable):
Beehive Eclipse Release

How reproducible:
Didn't try

Steps to Reproduce:
1.
2.see above
3.
    

Actual Results:  hangs on the first "std::cout <<" line

Expected Results:  Output to the console

Additional info:

Moved from mailing list my pmuldoon on behalf off blee for better tracking

see:
http://post-office.corp.redhat.com/archives/eclipse-list/2003-May/msg00133.html
http://post-office.corp.redhat.com/archives/eclipse-list/2003-June/msg00001.html

Comment 1 Keith Seitz 2003-06-11 20:29:00 UTC
In short: debugging applications with no debug info doesn't work very well.

When the CDT debugger hits a PC with no debug info, it appears to do nothing. In
fact, gdb HAS done something, but it just doesn't look like it.

Stepping into a system library is always going to be hit-or-miss in this
respect. Most of the time, it will be miss (system libraries stripped or do not
contain debug info). Even if you did have debug info, odds that one has the
source files for the libraries is slim at best.

Under the cover, the CDT is asking gdb for a particular source file (or for the
source file for a given PC), and gdb is saying, "I don't know." Well, the CDT
then just does nothing. It should open a disassembly window, so that at least
the user can see that there is no source. Alas, this option is disabled by
default in the CDT. Go to Window->Preferences->C/C++->Debug and select
"Automatically switch to disassembly mode" and it will operate as it should.

More under the cover: Imagine that you have a program like this:

int
main (int argc, char *argv[])
{
  std::cout << "Hello, world" << std::endl;
  return EXIT_SUCCESS;
}

You set a break at main. The debugger stops there. If the app has debug info,
gdb and the CDT will display the source for main(). If the app has no debug info
, the CDT will show nothing (or the disassembly if the preference is set).

Now you step into std::cout, a system library... What happens?

If your application has no debug info, gdb issues a warning that it doesn't know
how to figure out how to step (because there are no line numbers for the current
function, main()), and it steps until main() returns! This is normal behavior.

If your app has debug info and the library has no debug info, then gdb issues a
warning (which the CDT does not display anywhere) that it is going to step OVER
the function call, since it has no debug info for it. This is also normal behavior.

If your app has debug info and the library has debug info, then gdb and the cdt
will happily display the results of the step, but it will only be able to
display source code IF the source file is found on your system (in the same
place as the when the library was built, which is exceptionally unlikely).
[Mumble something about gdb's path command, which adds source file search paths,
but that's another topic.]

In short:
1) Don't try to step into a system library without having "automatically
switch..." set. 
2) Don't try to debug an executable with no debug info



Note You need to log in before you can comment on or make changes to this bug.