Embedded Studio Go To Definition/Declaration not working for functions outside of file

[jlienau03]

Hello,

I've been using  SES for ARM (Nordic Edition) V4.16 (64-bit).  I am working with nRF9160 sample code.  While attempting to explore the code, when I right click on a function or variable and try to 'Go To Definition' or 'Go To Declaration' nothing happens.  It cannot find the original definition of the function.  This makes it virtually impossible to explore the sample code as I can't go see function definitions and understand what they are doing.  

As an example:

In the GPS sample, in the 'enable_gps()' function within main.c, I tried right clicking and selecting Go To Definition for 'memcmp()' on line 65.  Nothing happens.  The Go To calls work properly for functions defined within the main.c file, for example 'process_gps_data().' But not if the function or variable is defined outside of the file I'm in.

Am I missing some setting in SES? I have compiled and built the solutions and tried using the Go To commands.  I am able to successfully program the DK and run the samples.   

Thanks!

[Øyvind]

Hello, 

The issue is, what I've been told, when you include CONFIG_NEWLIB_LIBC=y in prj.conf.

This one is the standard C lib that is included in the asset_tracker. SES cannot find the sources, as they are not actually there, they're supplied with the compiler as a static library (.a file). What VSCode finds is the minimalistic libc that is included in Zephyr, but it is not used in this specific sample. If you open up any other sample, like SPM, SES should be able to go to the definition without issues, as this sample uses Zephyr's libc.

-Øyvind

[awneil]

But that only explains stuff which is in that library.

And, even then, 'Go To Declaration' should work and go to the appropriate header.

And it doesn't explain the (many) other cases where SES fails to find declarations and/or definitions which are in the source.

[Øyvind]

I think you may have found issues that go even deeper than we thought. The issue I described is reported internally at least, and you have reported to Segger. Let's hope they find a solution soon.