Hide Forgot
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): How reproducible: Always Steps to Reproduce: 1.See above 2. 3. Additional info:
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 "list printf". 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.