| Help - debugger can't find source [message #93183] |
Mon, 02 February 2004 12:07  |
Eclipse User |
|
|
|
I have a project that builds a shared library, and I'm having problems
with the debugger finding the source, and setting breakpoints.
I'm running on Linux with gdb 5.2-2. Is this version of gbd sufficient?
I have the executable program linked into my project workspace. The
executable is optimized with no debug symbols, and the source is not
available.
I have a debug launch configuration set up to debug this executable. I
have the working directory set to a temporary directory. The debugger
starts up just fine and stops in main(). I hit continue, the executable
loads my shared library, and transfers control to the shared library
though an entry point function. The first line of code in the entry
point is raise(SIGUSR2). This stops the debugger so I can set
breakpoints in my code. If I attempt to set a breakpoint in my source
code, the debugger prints the error message: No source file named foo.C,
and a set breakpoint appears in the Breakpoints view. If I continue,
the breakpoint will not be triggered.
It appears that my problem is that CDT is not giving gdb the proper
source search paths. One thing to note is that my source code is in a
src/ tree, and the project is built in a build/ tree so the deubg
symbols in the .o files will be relative to build directory (ie ../src/
module/file.C). I've tried setting the build directory as an Additional
source directory in the debug launch configuration, but that does not
help.
Any ideas on how to get this to work? I cannot change the project
structure or build location/mechanism.
Bryan
|
|
|
| Re: Help - debugger can't find source [message #93197 is a reply to message #93183] |
Mon, 02 February 2004 12:09  |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
"Bryan Hunt" <bhunt@mac.com> wrote in message
news:20040202111049480-0600@news.eclipse.org...
> I have a project that builds a shared library, and I'm having problems
> with the debugger finding the source, and setting breakpoints.
>
> I'm running on Linux with gdb 5.2-2. Is this version of gbd sufficient?
>
Yes, it is.
> I have the executable program linked into my project workspace. The
> executable is optimized with no debug symbols, and the source is not
> available.
>
> I have a debug launch configuration set up to debug this executable. I
> have the working directory set to a temporary directory. The debugger
> starts up just fine and stops in main(). I hit continue, the executable
> loads my shared library, and transfers control to the shared library
> though an entry point function. The first line of code in the entry
> point is raise(SIGUSR2). This stops the debugger so I can set
> breakpoints in my code. If I attempt to set a breakpoint in my source
> code, the debugger prints the error message: No source file named foo.C,
> and a set breakpoint appears in the Breakpoints view. If I continue,
> the breakpoint will not be triggered.
>
> It appears that my problem is that CDT is not giving gdb the proper
> source search paths. One thing to note is that my source code is in a
> src/ tree, and the project is built in a build/ tree so the deubg
> symbols in the .o files will be relative to build directory (ie ../src/
> module/file.C). I've tried setting the build directory as an Additional
> source directory in the debug launch configuration, but that does not
> help.
>
The source search path is used by gdb to display the source code inside gdb
(for example, the "list" command) and has nothing to do with breakpoints.
gdb retrives the source files and line numbers from the debug information
provided by your executables. Type "info sources" in gdb console and you
will get the list of source files.
> Any ideas on how to get this to work? I cannot change the project
> structure or build location/mechanism.
>
> Bryan
|
|
|
|
|
| Re: Help - debugger can't find source [message #93238 is a reply to message #93222] |
Mon, 02 February 2004 15:23 |
| Eclipse User |
|
|
|
In <bvma82$jqi$1@eclipse.org> Mikhail Khodjaiants wrote:
>
> "Bryan Hunt" <bhunt@mac.com> wrote in message
> news:20040202123231958-0600@news.eclipse.org...
>>
>> > The source search path is used by gdb to display the source code
>> > inside gdb (for example, the "list" command) and has nothing to do
>> > with breakpoints. gdb retrives the source files and line numbers
>> > from the debug information provided by your executables. Type "info
>> > sources" in gdb console and you will get the list of source files.
>> >
>>
>> Yes, the problem is not with the source search path, but with our
>> build process. Our shared library consists of a number of modules
>> where a module is some number of .C files. Each module is compiled
>> as a single . o file, then linked into the shared library. We do
>> this by creating a module.All.C file that contains a #include for
>> each .C file in the module. CDT is attempting to set a breakpoint in
>> file foo.C, but foo.C is not known to gdb until module.All.C is read
>> in. Using "info sources" shows that module.All.C is in the list of
>> "Source files for which symbols will be read on demand".
>>
>
> As far as I understand you signal from your code to suspend the
> application when the library is loaded. What happens if you step?
>
If you step into the code, you can then set breakpoints, but stepping
into the code is not exactly straightforward. The code in the modules
is actually called periodically from a base library that contains the
main execution engine (and the signal that suspends execution after
being loaded from the executable). I have no problem stepping through
the execution engine (I wrote that code), but that is not practical for
all of the other users. The execution engine could call code in fifty
other modules before calling code in the module you want to debug.
One possible workaround would be to edit one of the functions in the
module to raise(SIGUSR2), then tell the debugger to ignore that signal.
You would then be able to set your breakpoints. This is still very
inconvenient.
Bryan
|
|
|
| Re: Help - debugger can't find source [message #93265 is a reply to message #93238] |
Mon, 02 February 2004 16:19 |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
"Bryan Hunt" <bhunt@mac.com> wrote in message
news:20040202142707617-0600@news.eclipse.org...
> In <bvma82$jqi$1@eclipse.org> Mikhail Khodjaiants wrote:
> >
> > "Bryan Hunt" <bhunt@mac.com> wrote in message
> > news:20040202123231958-0600@news.eclipse.org...
> >>
> >> > The source search path is used by gdb to display the source code
> >> > inside gdb (for example, the "list" command) and has nothing to do
> >> > with breakpoints. gdb retrives the source files and line numbers
> >> > from the debug information provided by your executables. Type "info
> >> > sources" in gdb console and you will get the list of source files.
> >> >
> >>
> >> Yes, the problem is not with the source search path, but with our
> >> build process. Our shared library consists of a number of modules
> >> where a module is some number of .C files. Each module is compiled
> >> as a single . o file, then linked into the shared library. We do
> >> this by creating a module.All.C file that contains a #include for
> >> each .C file in the module. CDT is attempting to set a breakpoint in
> >> file foo.C, but foo.C is not known to gdb until module.All.C is read
> >> in. Using "info sources" shows that module.All.C is in the list of
> >> "Source files for which symbols will be read on demand".
> >>
> >
> > As far as I understand you signal from your code to suspend the
> > application when the library is loaded. What happens if you step?
> >
>
> If you step into the code, you can then set breakpoints, but stepping
> into the code is not exactly straightforward. The code in the modules
> is actually called periodically from a base library that contains the
> main execution engine (and the signal that suspends execution after
> being loaded from the executable). I have no problem stepping through
> the execution engine (I wrote that code), but that is not practical for
> all of the other users. The execution engine could call code in fifty
> other modules before calling code in the module you want to debug.
>
I have had similar problem with the C++ classes with methods defined in the
header file. Changing the debug format helped. What is your debug format?
> One possible workaround would be to edit one of the functions in the
> module to raise(SIGUSR2), then tell the debugger to ignore that signal.
> You would then be able to set your breakpoints. This is still very
> inconvenient.
>
> Bryan
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05857 seconds
Home