June 14, 2018 at 18:53 #21103
I have an ESP-IDF project that does something a little unusual. This is actually the same project that I referred to earlier under the topic:
I am unable to set any breakpoints in this project. When I attempt to do so, they set but then display an Exclamation point and say “The breakpoint will not currently be hit. Cannot resolve breakpoint location.”
I am suspicious that the problem is related to a .o file that is linked into the final output but does not originate from code. It originates from html files that are compressed with a custom tool and then inserted into the output.
The output from a simulated build for that .o file is like this:
cd /cygdrive/c/Users/Don/Documents/esphttpd-freertos/html/ && find . | /cygdrive/c/Users/Don/source/repos/EmbeddedProject12/EmbeddedProject12/VisualGDBCache/EmbeddedProject12-Debug/CodeSenseDir/libesphttpd/mkespfsimage/mkespfsimage > /cygdrive/c/Users/Don/source/repos/EmbeddedProject12/EmbeddedProject12/VisualGDBCache/EmbeddedProject12-Debug/CodeSenseDir/libesphttpd/webpages.espfs
xtensa-esp32-elf-objcopy -I binary -O elf32-xtensa-le -B xtensa –rename-section .data=.rodata \
xtensa-esp32-elf-gcc -nostdlib -Wl,-r webpages.espfs.o.tmp -o webpages.espfs.o -Wl,-T /cygdrive/c/Users/Don/Documents/esphttpd-freertos/components/libesphttpd/webpages.espfs.esp32.ld
xtensa-esp32-elf-ar cru libwebpages.espfs.a webpages.espfs.o
The odd thing is that on the Solution Explorer, the name of the project is shown as webpages.espfs, I do not know why that is happening, but I attached a screen shot.
The even odder thing is that if I open the properties of the ESP-IDF project (not the VisualGDB project properties) and then click on the Debug tab, I see the text “Failed to locate the component containing /cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/libesphttpd/webpages.espfs.o” instead of True or False on “Disable Optimization in Debug Build”. See the second attached screenshot.
I think the presence of this .o file which is produced in this unusual way is messing up some parsing somewhere, but I don’t really even know where to start to look for it.
If you have any suggestions I would sure like to hear them.
DonJune 15, 2018 at 02:00 #21116
If that’s the same project based on custom Makefiles (not following the regular ESP-IDF Makefile structure), many GUI features of VisualGDB won’t work properly (they rely on a specific Makefile structure of the regular ESP-IDF projects).
The breakpoint errors should be completely solvable though. Please use the “Diagnose Breakpoint Problems” button in the GDB Session window (it is explained in this tutorial, although it features an older VisualGDB version). If it doesn’t help, please create and share a full gdb log showing the exact commands sent while trying to set the breakpoints and we will advise you on the correct settings to fix this.June 15, 2018 at 11:54 #21126
Thanks for the quick response. I wasn’t really concerned about the GUI features I just thought they might provide insight into the problem with the breakpoints.
I tried the Diagnose Breakpoint Problems button. The results are shown in the image attached. It appears no symbols are loaded. The translated path is correct.
I also created the detailed GDB log as you requested, it is attached also. The problem seems to happen at line 150, though I suspect the real problem is much earlier.
PS: The forum wouldn’t accept a .log file so I had to put it in a .zip file.
DonJune 15, 2018 at 22:05 #21139
Thanks for the log file. Looks like VisualGDB incorrectly determines the path to the main binary built by the project. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-126.96.36.1995.msi
Before opening the project, please enable debug logging in View->Other Windows->VisualGDB Diagnostics Console and then attach the debug output produced while opening the project. It should contain lines like “ESP-IDF code model: found xxx targets” listing the targets discovered from the esp-idf log.June 16, 2018 at 14:41 #21141
I ran the installer you sent me but it didn’t seem to make any difference.
I collected two VisualGDB Diagnostics logs and have attached them here.
The first is after I cleaned the project, closed the solution, copied the one .exe into VisualGDBCache so that the project would load and then loaded it.
The second is after I did a successful build, closed the solution and then opened it again.
DonJune 17, 2018 at 00:33 #21146
Thanks for running this. This build didn’t contain any fix yet – it only contained extra logging that helped us understand what was causing the problem. Turns out the customization to the project made VisualGDB treat the ESPFS pseudo-binary as the primary project output (see second line below):C++123/cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/bootloader/bootloader.elf: 0 inputs, IsStaticLibrary=False/cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/libesphttpd/webpages.espfs.o: 0 inputs, IsStaticLibrary=False/cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/webserver.elf: 0 inputs, IsStaticLibrary=False
Now that we have pinpointed the root cause, we were able to fully fix it. Please try this build, it should work out-of-the-box (you may still need to clean the project): http://sysprogs.com/files/tmp/VisualGDB-188.8.131.526.msiJune 18, 2018 at 12:59 #21148
That fixed it. The first time I tried to set a breakpoint (after an extensive clean) a message appeared prompting me to enter a mapping rule. I had to enter the mapping rule and then it worked properly.
Thanks for all your help.
You must be logged in to reply to this topic.