From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922
Description of problem:
When a Step into command is issued on a library function (like printf)
should open the file printf.c At present the debugger knows the
location of the file but it is asking us to do it manually.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I'm not quite sure what you mean when you say "At present the debugger
knows the location of the file but is asking us to do it manually."
Does that mean that the debug UI has stepped into printf but cannot
display the source file? Or does it step OVER the function call?
There is one way to check what is happening: run command-line gdb on
your executable. Just load it ("file myexe"), and then ask for info
about printf ("info func printf").
If gdb says something like "non-debugging symbols: printf", then gdb
did NOT find debug information for printf, and when asked to step into
it, it will actually step OVER it.
However, if it returns something else (like a filename), then try
If gdb lists the function, then we're definitely looking at a CDT
debugger UI bug.
If gdb cannot list the file, then it is possible that the debug info
is "wrong". I don't know whether we taught gdb to know about the
debuginfo rpms and the like, though.
It is more likely that the file doesn't exist where gdb thinks it is
supposed to. Again, the output of "info func printf" should tell you
where gdb thinks the file is. Try inspecting the EXACT path mentioned
by gdb in the filesystem.