Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » C / C++ IDE (CDT) » Simple test case not finding include files(Include Files not found from User Settings Include Paths)
Simple test case not finding include files [message #1781320] Tue, 06 February 2018 02:26 Go to next message
Chad Farmer is currently offline Chad FarmerFriend
Messages: 7
Registered: February 2018
Junior Member
I'm trying to understand how the Eclipse project configuration and CDT C parser work.

To set up a simple test, I've disabled all Preprocessor Include Paths Providers except for "CDT User Setting Entries". To that I've added defines, include paths, include files, etc. In the attached png screenshot, the existence of my User Defined Include directories can be seen in Project Explorer under "Includes".

The "Search" tab shows the start of a much longer list of errors produced by "Index -> "Search for Unresolved Includes". The project is named "linux-bmc". I assure you that "linux-bmc/include" contains "linux/compiler.h" and "linux/string.h", etc.

In my mind, I've told the parser where to look for include files, and it is not finding them.

Can someone suggest the (probably obvious ) thing I'm doing wrong?

ps: when I say simple test, I'm talking about the number of options I'm setting, not the size of the project.

Version: Oxygen.2 Release (4.7.2)
Build id: 20171218-0600
Installed from eclipse-cpp-oxygen-2-linux-gtk-x86_64.tar.gz (sha512 verified)
Re: Simple test case not finding include files [message #1781412 is a reply to message #1781320] Wed, 07 February 2018 01:46 Go to previous messageGo to next message
David VavraFriend
Messages: 720
Registered: October 2012
Senior Member
You haven't shown the User Entries you are using.
It should at least have "linux-bmc/include"
Using paths relative to the project or workspace are OK but
I recommend defining then while using the drop down menu in the upper right of the "Add" dialog.

index.php/fa/32022/0/

FYI: The displayed user entry for LOCALLIB/inc is a different directory than ${project}/inc that I have selected.
Pushing the folders button shows the folders relative to the current project.

index.php/fa/32024/0/

Here's the result
index.php/fa/32027/0/

[Updated on: Wed, 07 February 2018 02:07]

Report message to a moderator

Re: Simple test case not finding include files [message #1781494 is a reply to message #1781412] Wed, 07 February 2018 21:34 Go to previous messageGo to next message
Chad Farmer is currently offline Chad FarmerFriend
Messages: 7
Registered: February 2018
Junior Member
Thanks for reading my message and replying. [I should have added my image to the body, rather than only as an attachment.] With respect to the original attachement, the Project Explorer pane "Includes" items are include directories in the configuration (this is different from the directory "includes").

In the Project Explorer pane, it is odd that include directories entered as "file system path" show subordinate directories and include files, but include directories within the Project do not show any subordinate detail. Its been a few days, but I believe it doesn't matter how the include directory is entered. CDT recognizes the path as being inside the project and doesn't show any detail.

Back to the problem

I don't understand why the indexer is not finding include files that are in configured include directories.

I deleted the project and created it again, this time specifying toolchain <none>. I un-selected the two other Providers, leaving only "CDT User Setting Entries". As before, I added all the include files, include directories, preprocessor macros, etc. When I clicked "Close and Apply", the indexer ran. After it finished, I noticed that I had forgotten to set source filters to eliminate non-arm architecture files under ./arch, ./arch/mach-<other>, and ./include/asm-<other>. I set the filters and the indexer ran (after sending an error report). In any case, Index -> Rebuild did not report another error.

I did project Index -> Search for unresolved includes. The results follow.

index.php/fa/32038/0/

And before anyone asks, I do have the User Entries setup.

index.php/fa/32037/0/
Re: Simple test case not finding include files [message #1781508 is a reply to message #1781494] Thu, 08 February 2018 00:49 Go to previous messageGo to next message
Chad Farmer is currently offline Chad FarmerFriend
Messages: 7
Registered: February 2018
Junior Member
I'm not sure if it is related, but I should mention that I'm not building with Eclipse. The actual build process is script driven and runs in a container that can't host a current Eclipse.

Following are my current Index Settings. Some Eclipse documentation suggests choosing between Fast and Full indexers. I don't see any way to do that.

index.php/fa/32041/0/

Re: Simple test case not finding include files [message #1781589 is a reply to message #1781508] Fri, 09 February 2018 04:19 Go to previous messageGo to next message
David VavraFriend
Messages: 720
Registered: October 2012
Senior Member
Well, I don't know. I've never experienced anything like that.
You may be able to track it down by producing a parser log of misc.c
Project --> C/C++ Index --> Create Parser Log File
Despite what you say, this isn't a simple test case.
Try it with something a lot smaller then work up to your current case.

[Updated on: Fri, 09 February 2018 04:19]

Report message to a moderator

Re: Simple test case not finding include files [message #1781632 is a reply to message #1781589] Fri, 09 February 2018 19:55 Go to previous messageGo to next message
Chad Farmer is currently offline Chad FarmerFriend
Messages: 7
Registered: February 2018
Junior Member
Thanks, I need some help in debugging CDT.

Attached is the parser log file for misc.c. Note that arch/arm/boot/compressed/misc.c is just the first file parsed, so its warning is at the top of the "Search for unresolved includes" output.

Following is a summary of the attached file. From my naive perspective, the log file reports the correct include search paths and then fails to search them.

My Linux build has 22 string.h files, but there is only one "linux/string.h".

Build Configuration:   Default
Context:               file:/home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c
   C, {}
Versions in Index:     1
   C: {}; 21 macros, 6 includes, 120 names;

Include Search Path (option -I):
   /builds/fedora10/usr/lib/gcc/armv4-pp004-linux-uclibcgnueabi/4.3.2/include
   /home/cfarmer/test/newsdk2/install_root_final/include/local/shared

Local Include Search Path (option -iquote):
   /home/cfarmer/test/newsdk2/linux/include
   /home/cfarmer/test/newsdk2/linux/arch/arm/include
   /home/cfarmer/test/newsdk2/linux/arch/arm/mach-pilot3bulldc/include

Preincluded files (option -include):
   /home/cfarmer/test/newsdk2/linux/include/linux/autoconf.h
   /home/cfarmer/test/newsdk2/pp_features.h

Macro definitions (option -D):
   KBUILD_BASENAME=KBUILD_STR(main)
   KBUILD_MODNAME=KBUILD_STR(main)
. . .
Macro definitions (from files actually parsed):
   arch_error(x)=
   ARCH_HAS_DECOMP_WDOG=
   Assert(cond,msg)=
   Assert(cond,msg)={if(!(cond)) error(msg);}
   flush()=do { } while (0)
   get_byte()=(inptr < insize ? inbuf[inptr++] : fill_inbuf())
   NO_INFLATE_MALLOC=
   OF(args)=args
   putc(ch)=icedcc_putc(ch)
   putstr=printf
   putstr_info(x)=
   putstr_info=putstr
   STATIC=static
   Trace(x)=
   Trace(x)=fprintf x
   Tracec(c,x)=
   Tracec(c,x)={if (verbose && (c)) fprintf x ;}
   Tracecv(c,x)=
   Tracecv(c,x)={if (verbose>1 && (c)) fprintf x ;}
   Tracev(x)=
   Tracev(x)={if (verbose) fprintf x ;}
   Tracevv(x)=
   Tracevv(x)={if (verbose>1) fprintf x ;}
   WSIZE=0x8000
   __ptr_t=void *

Unresolved includes (from headers in index):
   Unresolved inclusion: linux/compiler.h in file file:/home/cfarmer/test/newsdk2/linux/lib/inflate.c

Scanner problems:
   Unresolved inclusion: <linux/string.h> in file: /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:21
   Unresolved inclusion: <linux/compiler.h> in file: /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:29
   Unresolved inclusion: <mach/uncompress.h> in file: /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:30

Unresolved names:
   Attempt to use symbol failed: size_t in file /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:98
   Attempt to use symbol failed: size_t in file /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:141

[b]For the "show me" people (like myself):[/b]
[cfarmer@fc10.bmcbuild ~]$ ls -l /home/cfarmer/test/newsdk2/linux/include/linux/string.h
-rw-rw-r-- 1 cfarmer cfarmer 3344 2016-02-15 13:49 /home/cfarmer/test/newsdk2/linux/include/linux/string.h
[cfarmer@fc10.bmcbuild ~]$ ls -l /home/cfarmer/test/newsdk2/linux/include/linux/compiler.h
-rw-rw-r-- 1 cfarmer cfarmer 5771 2016-02-15 13:49 /home/cfarmer/test/newsdk2/linux/include/linux/compiler.h
[cfarmer@fc10.bmcbuild ~]$ ls -l /home/cfarmer/test/newsdk2/linux/arch/arm/mach-pilot3bulldc/include/mach/uncompress.h
-rw-rw-r-- 1 cfarmer cfarmer 40 2016-02-15 13:49 /home/cfarmer/test/newsdk2/linux/arch/arm/mach-pilot3bulldc/include/mach/uncompress.h


As far as simple test case is concerned, I understand the benefit, but I've never had a problem with hello world. Creating a useful simple test case would involve a lot of trial-and-error or knowing what the problem is.
Re: Simple test case not finding include files [message #1781638 is a reply to message #1781632] Fri, 09 February 2018 22:52 Go to previous messageGo to next message
Chad Farmer is currently offline Chad FarmerFriend
Messages: 7
Registered: February 2018
Junior Member
I've been looking at the log file for Index -> Create Parser Log Files for ./arch/arm/boot/compressed/misc.c.

Despite parsing misc.c, "Unresolved includes (from headers in index):" starts with a reference to inflate.c. This is because misc.c contains
248:#include "../../../../lib/inflate.c"
. Perfectly legal, but unusual. Of course the missing file, linux/compiler.h, exists under <proj>/include.

I looked at the report labeled "Macro definitions (from files actually parsed):". These macros appear to be defined in misc.c. Unfortunately, they are reported in alphabetical order, not scan order. And it does not report the file/line # where defined. But it appears the the parser is not processing #ifdef statements.

File misc.c contains the following lines:
/* Diagnostic functions */
#ifdef DEBUG
#  define Assert(cond,msg) {if(!(cond)) error(msg);}
#  define Trace(x) fprintf x
#  define Tracev(x) {if (verbose) fprintf x ;}
#  define Tracevv(x) {if (verbose>1) fprintf x ;}
#  define Tracec(c,x) {if (verbose && (c)) fprintf x ;}
#  define Tracecv(c,x) {if (verbose>1 && (c)) fprintf x ;}
#else
#  define Assert(cond,msg)
#  define Trace(x)
#  define Tracev(x)
#  define Tracevv(x)
#  define Tracec(c,x)
#  define Tracecv(c,x)
#endif


The CDT editor correctly shades the first section as not being used (DEBUG is not defined). But the parse log output shows values defined from BOTH LEGS of the #ifdef.

I don't know what to say about that. Skipping conditional code seems so fundamental that I must be missing something obvious. Help.

The parser log file includes the following:
Macro definitions (from files actually parsed):
   arch_error(x)=
. . .
   STATIC=static
   Trace(x)=
   Trace(x)=fprintf x
   Tracec(c,x)=
   Tracec(c,x)={if (verbose && (c)) fprintf x ;}
   Tracecv(c,x)=
   Tracecv(c,x)={if (verbose>1 && (c)) fprintf x ;}
   Tracev(x)=
   Tracev(x)={if (verbose) fprintf x ;}
   Tracevv(x)=
   Tracevv(x)={if (verbose>1) fprintf x ;}
   WSIZE=0x8000
   __ptr_t=void *

Re: Simple test case not finding include files [message #1781640 is a reply to message #1781638] Sat, 10 February 2018 03:51 Go to previous messageGo to next message
David VavraFriend
Messages: 720
Registered: October 2012
Senior Member
The problem likely resulted from a misinterpreted #if
CDT doesn't handle these well especially if multiple interpretations are possible.
One reason is the cache can have only one value and the value may depend on the reading order.

You could try using the -E GCC option to get the output of the preprocessor.
It's not necessarily what CDT is doing but it may provide a clue.
Reading it would be tedious.

Equally tedious is to comment out large sections of code to shorten the scan.
Doing this judiciously may pinpoint the place where CDT goes wrong.
This is really just making a smaller example that eventually grows.

Sorry about the generalities but without all of your code there isn't much anyone else can do.
Needless to say, nothing jumps out at me.

UPDATE:
You could try forcing the values used by #if that only the CDT parser can see.
Surround them like so:
#ifdef __CDT_PARSER__
:
#define SAMPLE 1
:
#endif


[Updated on: Sat, 10 February 2018 04:25]

Report message to a moderator

Re: Simple test case not finding include files [message #1781742 is a reply to message #1781640] Mon, 12 February 2018 21:43 Go to previous messageGo to next message
Chad Farmer is currently offline Chad FarmerFriend
Messages: 7
Registered: February 2018
Junior Member
Again, thank you for helping. I don't understand what some of the Indexer options actually do, so I might have a setting that is preventing the result I want.

I have specified Indexer options:

    Set Project Specific Settings
    Set Store Settings with Project, Enable Indexer
    Set Index source files not included in the build (Since I'm not building with Eclipse, I assume it doesn't know which files are included. If it is looking for existing ".o" files, I can could set this.)
    Set Index unused headers are C files
    Not set index all header variants (I don't know what it does, but setting it does not help my problem.)
    Set Index source and header files opened in editor (I don't now if this matters.)
    Not set Allow heuristic resolution of includes (seems enable less-than-correct parsing in the name of speed.)
    Set skip files larger than to 100 MB (I don't want to skip files.)
    Not set any of of the "Skip" options.
    Set Use a fixed build configuration (Not sure what active does.)

I need for CDT to follow the C preprocessor rules as it is parsing each source file. I'm willing to let the parser run for hours if it will produce results that match the actual build. The Fast/Full option seems to have disappeared. Is Full now the default?

I disabled The GCC Build Output Parser, because I wasn't sure what it did with Linux. Since I've done a Linux build, there is a <module>.o file (ELF with debug) and a .<module>.o.cmd file (gcc command line with -D, -I, -include, etc.) for every module built. My guess was the BOP wanted to run build (make) commands to see the output. Is there a BOP that looks at existing .o and .cmd files to guide the parser?

I'm not sure what you mean by " the cache can have only one value and the value may depend on the reading order". For any line of source (including #if statements) a macro is either undefined or has one value.

Re: Simple test case not finding include files [message #1781748 is a reply to message #1781742] Tue, 13 February 2018 00:05 Go to previous messageGo to next message
David VavraFriend
Messages: 720
Registered: October 2012
Senior Member
Quote:
For any line of source (including #if statements) a macro is either undefined or has one value.


FWIW: undefined is also a value.
Think of it as similar to the floating value NaN.
Eclipse CDT uses caching to accelerate the scan.
Presumably by obviating the rereading of headers.

The cache can retain only one value -- the latest encountered.
This means that a macro with multiple definitions may have the wrong value when evaluated.

You can try disabling the indexer but this means that no values will be remembered.
You can try playing with the Indexer options but I don't think you can turn off caching.

If you have macros with multiple values (say configuration macros) you can try forcing them as I mentioned above.

There is a way to specify that the active configuration would be used. Not sure if that means there are multiple indices.

Another option might be to keep multiple configurations in separate projects.

[Updated on: Tue, 13 February 2018 11:44]

Report message to a moderator

Re: Simple test case not finding include files [message #1781834 is a reply to message #1781748] Tue, 13 February 2018 18:22 Go to previous messageGo to next message
Chad Farmer is currently offline Chad FarmerFriend
Messages: 7
Registered: February 2018
Junior Member
"undefined is also a value" -- Agreed, I just didn't want to forget about #undef and never defined.

The (old) Linux build I'm doing uses ccache to avoid reparsing include files. Also, Linux caches the make rule for each source file in a file .<file>.o.cmd. This file contains the gcc command line with options and a rule make dependencies on that source file's include files.

Are there any CDT components/plugins that could use the ccache data? That would avoid trying a fast but inaccurate approximation of the C preprocessor.

Using the ".cmd" file could be an alternative to running gcc commands from CDT.

Are there any projects to improve the accuracy of the CDT preprocessor?

Thanks again for the explanations and help.
Re: Simple test case not finding include files [message #1783322 is a reply to message #1781320] Mon, 12 March 2018 03:46 Go to previous message
Tim Cook is currently offline Tim CookFriend
Messages: 30
Registered: September 2010
Member
Here's my 2 cents! :)

I administer our Eclipse Program configurations which may include several projects. I'm continually refining our configurations based on user feedback.

I have found that Eclipse does a very good job at parsing source (.c/.h) source files for symbol information.
We use Eclipse for editing, static code analysis (codan), syntax highlighting, custom code style formatter, custom code templates and building.

Our build is script driven; we don't build with any Eclipse support tool chains. But to get the indexer support, a supported toolchain needs to be selected. Getting the indexer to behave the way we require, took many hours of trail & error. Including many 'start overs' (starting a workspace & project from scratch).

So I've included screen captures about creating a 'C' project (externally built) and indexer configuration. Hopefully, it helps. The one negative about Eclipse CDT is that sometimes there are interactions which are obscure. ;(

We build C programs for embedded platforms on Windows 7.

Tim


Major System Configuration:
Windows 7 64-bit
Eclipse IDE for C/C++ Developers
v 4.7.3RC2 (Oxygen)
v 4.8.m5 (Photon)

PyDev

MinGW
MSys
GNU Toolchain
Perforce
Previous Topic:RE: Running Some Software Out of a Book
Next Topic:"nice to meet you" program help
Goto Forum:
  


Current Time: Thu May 24 21:18:15 GMT 2018

Powered by FUDForum. Page generated in 0.02423 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top