ESP32 IDF project – Clang global symbol cache update hangs

Sysprogs forums Forums VisualGDB ESP32 IDF project – Clang global symbol cache update hangs

This topic contains 6 replies, has 2 voices, and was last updated by  support 2 weeks, 1 day ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #31341

    felixcollins
    Participant

    When I try a “find all references” on a asymbol it kicks off a global symbol cache update which hangs.  How can I investigate this and get it working?

    Attachments:
    You must be logged in to view attached files.
    #31343

    felixcollins
    Participant

    Tried again. This time it gets to 99% then hangs spinning the cpu.

    Attachments:
    You must be logged in to view attached files.
    #31346

    support
    Keymaster

    Hi,

    No problem, we can investigate this further. Please try updating to VisualGDB 5.6 Beta 5. If the problem persists, please try reproducing it on a clean project from scratch and sharing the repro steps we could follow on our side per our problem reporting guidelines.

    #31737

    felixcollins
    Participant

    It is still doing it…  It seems to be just that file.  “sha1-internal.c”   I tried creating a new project from one of the esp32 ble samples and it worked with that.

    Is there any way I can exclude that file?

    Thanks.

     

    #31738

    support
    Keymaster

    Hi,

    No problem, you can wrap the contents of the file with #ifndef __SYSPROGS_CODESENSE__. This will effectively hide the file from IntelliSense, while still building it as usual.

    #31763

    felixcollins
    Participant

    It is a system lib. I’m not using anything that uses it as far as I’m aware, but it must be coming in from somewhere. Is there anything in the project file to allow excluding files?

    #31770

    support
    Keymaster

    Hi,

    We have just rechecked the sha1-internal.c file on ESP-IDF 4.3.1 and it worked just fine (it was not used by default until we manually disabled mbedtls crypto), so the issue could be specific to a particular project or a particular machine.

    Either way, adding the __SYSPROGS_CODESENSE__ wrapper will not affect the build results (this macro is only set by the IntelliSense engine), so it should be safe to do even for library files. Due to the optimization used by VisualGDB to handle large file sets, hiding specific files from IntelliSense would be rather non-trivial, so unless the __SYSPROGS_CODESENSE__ workaround breaks specific functionality, we would advise using it instead.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.