|
|
|
| Re: What is the best/correct way to specify debugger source containers for an external makefile proj [message #1748473 is a reply to message #1748465] |
Wed, 23 November 2016 12:59   |
David Vavra
Messages: 1426
Registered: October 2012 |
Senior Member |
|
|
Doesn't appear to have been materially changed in NEON from MARS.
The Add button is adding mostly whole directories and subdirectories.
Workspace Folder allowed me to add a single folder from the selected workspace.
File System Directory allowed me to add a selected directory from the file system.
[i]Workspace[/] added every project tree in the workspace.
The name of your project is "master"?
It has been added to the configuration already.
If the list in the configuration contains the source directory of interest I would think gdb would find it.
Did you try dumping the debug information in the executable?
Doing so may give you a clue as to how to specify the source location.
You can run gdb as a stand-alone to see what it is up to.
You can also interact with gdb from the gdb console in Eclipse when debugging.
There are a number of commands related to the gdb search list.
One of the is show substitute-path
Although I didn't get anything when I tried it. Eclipse may not use it.
Here's the full command list: https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html
FWIW:
I also got three messages saying source could not be found.
None of them are in my program but there are old breakpoints to them.
I can see Eclipse trying to set them in the gdb Trace console (I've shown the last).
Apparently old information as there are no breakpoints currently set in the source.
bkpt={number="6",type="breakpoin\
t",disp="keep",enabled="y",addr="<PENDING>",pending="/home/dvavra/proj/HCP-FANN/src/Train.cpp:277",t\
imes="0",original-location="/home/dvavra/proj/HCP-FANN/src/Train.cpp:277"}]
No source file named /home/dvavra/proj/knnl-0.1.4/knnl/source/main.cpp.
No source file named /home/dvavra/proj/fann/src/fann_io.c.
No source file named /home/dvavra/proj/HCP-FANN/src/Train.cpp.
These I ignore.
If gdb can't find the source, when you step into it, Eclipse will offer to display the disassembly.
|
|
|
| Re: What is the best/correct way to specify debugger source containers for an external makefile proj [message #1748487 is a reply to message #1748473] |
Wed, 23 November 2016 14:49 |
 Roger James
Messages: 8
Registered: November 2016 |
Junior Member |
|
|
Hi David,
With just the normal default source container tree set. The debugger can find files in any files in the diectories in and below the directory where the main executable resides. In my case this is
/home/roger/mythdev/mythrfj/mythtv/programs/mythbackend
Files from anywhere else in my source tree such as
/home/roger/mythdev/mythrfj/libs/libmythtv
Cannot be found.
If I delete the default container and replace with a project source container identical to the one under the default container. Then no files at all can be found. This means that files are being found by either the absolute file path container or the program relative containers, show that the files are being found via the absolute path container. Repeating the experiment I did with the project source container with the other containers, I found that files were being found by the absolute path container. I also found out that neither of these containers have parameters (which is probably why you cannot edit them to see what they are set to). So it means that means that they are finding source by some kind of algorithm. Which goes back to one of my original questions. Where is this stuff documented?
But that leaves me with my problem with finding files from other parts of my source tree.
Quote:
Re: What is the best/correct way to specify debugger source containers for an external makefile proj Wed, 23 November 2016 12:59
David Vavra
Doesn't appear to have been materially changed in NEON from MARS.
The Add button is adding mostly whole directories and subdirectories.
//https://kichwacoders.com/2016/04/12/improved-cdt-source-lookup-path-mappings-in-neon/
Quote:
Workspace Folder allowed me to add a single folder from the selected workspace.
File System Directory allowed me to add a selected directory from the file system.
[i]Workspace[/] added every project tree in the workspace.
The name of your project is "master"?
It has been added to the configuration already.
Yes. I know.
Quote:
If the list in the configuration contains the source directory of interest I would think gdb would find it.
It doesn't. See above.
Quote:
Did you try dumping the debug information in the executable?
Doing so may give you a clue as to how to specify the source location.
I mentioned doing that in my original message  . The source paths in the debug info are all absolute paths that are correct for my file system. Here is one that is found by absolute path container.
0000000000000000 T _ZN28MythBackendCommandLineParserC1Ev /home/roger/mythdev/mythrfj/mythtv/progr
ams/mythbackend/commandlineparser.cpp:6
and here is one that is not
0000000000001388 r _ZZN11EitCacheDVB13ScheduleTable14ProcessSectionEPK24DVBEventInformationTablebR4QMapIy28QExplicitlySharedDataPointerINS_5EventEEEyE12__FUNCTION__ /home/roger/mythdev/mythrfj/mythtv/libs/libmythtv/eitcachedvb.cpp:310
Quote:
You can run gdb as a stand-alone to see what it is up to.
You can also interact with gdb from the gdb console in Eclipse when debugging.
There are a number of commands related to the gdb search list.
One of the is show substitute-path
Although I didn't get anything when I tried it. Eclipse may not use it.
Here's the full command list: https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html
I tried all that a number of times. The substitute search path is empty when the debugger is run by eclipse.
Quote:
FWIW:
I also got three messages saying source could not be found.
None of them are in my program but there are old breakpoints to them.
I can see Eclipse trying to set them in the gdb Trace console (I've shown the last).
Apparently old information as there are no breakpoints currently set in the source.
bkpt={number="6",type="breakpoin\
t",disp="keep",enabled="y",addr="<PENDING>",pending="/home/dvavra/proj/HCP-FANN/src/Train.cpp:277",t\
imes="0",original-location="/home/dvavra/proj/HCP-FANN/src/Train.cpp:277"}]
No source file named /home/dvavra/proj/knnl-0.1.4/knnl/source/main.cpp.
No source file named /home/dvavra/proj/fann/src/fann_io.c.
No source file named /home/dvavra/proj/HCP-FANN/src/Train.cpp.
If eclipse is setting them, then Run/Remove All Breakpoints should get rid of them. 
I am struggling to make sense of all this. Eclipse is a steep learning curve for me.
I am going to try adding absolute path containers individually for the libraries. But this does not seem the right way to do this.
I am now convinced that the "source file not found" messages are being generated by eclipse from the returns from the gdb api and that the text of the messages does not accurately represent what gdb has been asked to look for.
Any comments anyone.
Cheers
Roger
|
|
|
| Re: What is the best/correct way to specify debugger source containers for an external makefile proj [message #1748501 is a reply to message #1748487] |
Wed, 23 November 2016 16:24 |
David Vavra
Messages: 1426
Registered: October 2012 |
Senior Member |
|
|
The gbd trace should show what actions correspond to the messages. When I debug with ddd vs. Eclipse I don't get the errors which are the result of Eclipse setting phantom breakpoints. Run/Remove All Breakpoints likely would remove them but it wasn't my point (granted I wasn't clear enough) and not something I care to do.
I don't have any problems with symbols and breakpoints in the two libraries that I refence from this project. Note they aren't even mentioned in the debug configuration. In fact, adding the directories for the sources in the missing messages in my post won't fix anything because they really don't exist in the executable.
Maybe you should to submit a bug report instead of posting here but you should submit a gdb trace with it.
|
|
|
Powered by
FUDForum. Page generated in 0.03162 seconds
] 
Search
Help
Register
Login
Home
).