Bug 84612 - gdb source path problem with C++
gdb source path problem with C++
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: gdb (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexandre Oliva
Jay Turner
david@millersweb.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-19 11:29 EST by Need Real Name
Modified: 2015-01-07 19:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 14:18:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-02-19 11:29:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
On RedHat 7.3 I had no problems compiling and testing C++ code.  Now that I have
8.0 using the gcc 3.2 compiler code compiles and runs fine but when I try to use
gdb or ddd they complain about not being able to find source headers that they
are looking for in the build directory.  gdb looks in the current working
directory and the directory where the source for the object was compiled from.  

It appears that in the past, when libriaries were built that they used headers
in the normal /usr/include path but with 8.0 the headers were in the build path.
 On a system that doesn't have source for all packages loaded in the build path
you get these errors when debuging.

It appears that the libirarys need to be compiled with the headers in the
correct place or gdb has to be setup with hard coded paths to each sub directory
in in /usr/include.

Can you explain if I am misunderstanding the problem.

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


How reproducible:
Always

Steps to Reproduce:
1.I built a main.cpp that called a constructor of a class.  That was all there
is in main.
2.The constructor has 7 or 8 lines of code.
3. start ddd or gdb and set a break point at main.  Single step into the
constructor of the class.
    

Actual Results:  Doing the above results in getting a message that indicates
that source files can't be found and gives a path to where it expects a header
file to be.  This path is in the build directory.  Single step continues a
machine instruction at a time on each step repeating the message until it
returns back to the class you generated.

Expected Results:  When steping through code and execution goes through a piece
of code that is not part of my source, code from a library or other system code,
I would expect the debugger to make the step accross that entire piece of code
as one step and not give any error messages about not being able to find source.
 If I step by instruction I expect to then see machine code without source for
code that comes from these librarys.  That is unless I generated the library and
had debugging turned on when I compiled it and then I would expect it to look
like any other code.

Additional info:

(gdb) s
std::basic_ostream<char, std::char_traits<char> >& std::operator<<
<std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&,
char const*) (
    __out=@0x40012020, 
    __s=0x80497a0 "Welcome to the tracking program for the troop. ")
    at
/usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/ostream.tcc:624
624
/usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/ostream.tcc:
No such file or directory.
	in
/usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/ostream.tcc
(gdb)
Comment 1 Elena Zannoni 2003-08-25 13:33:58 EDT
Does this still happen in a newer configuration? Newer gdb, and libstdc++?
If it does, can you include a log of the gdb sessin, how the program was
compiled and the source file?
Comment 2 Bill Nottingham 2006-10-18 14:18:46 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
If this issue is still present in a current Fedora Core release, please
open a new bug with the relevant information.

Closing as CANTFIX.

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