[Feature Request]: Option to omit stopping at app_main (VSC-1438)

[gudvinr]

Is your feature request related to a problem? Please describe.

I never break on app_main entry unless I want to specifically debug startup process from get-go.

You can't simply set breakpoint whenever you want and then build, flash and wait for breakpoint to trigger.
You need to wait for app_main triggering first and then continue.

Describe the solution you'd like

Add an option to suppress breaking on app_main.

esp_debug_backend already has start_func parameter in exec_run, which can be set to empty string to skip adding breakpoint.

Describe alternatives you've considered

Additional context

[brianignacio5]

So by default the new debug adapter has these init commands (not written in launch.json itself but in extension code):

"initCommands": [
        "set remote hardware-watchpoint-limit {IDF_TARGET_CPU_WATCHPOINT_NUM}",
        "mon reset halt",
        "maintenance flush register-cache",
        "thb app_main"
      ],

You can open the launch.json and modify initCommands to remove line that sets breakpoint in app_main thb app_main.

"initCommands": [
        "set remote hardware-watchpoint-limit {IDF_TARGET_CPU_WATCHPOINT_NUM}",
        "mon reset halt",
        "maintenance flush register-cache"
      ],

[gudvinr]

Should be good enough as a workaround but suboptimal as the solution.

Startup commands can change after extension update and one must inspect source code after every release to match custom commands

On the other hand, cortex debug has runToEntryPoint

[brianignacio5]

How about we add the c after the thb app_main as done in here ?

I'm trying to keep default behavior as default as possible. Although is possible to add something like runToEntryPoint a regular will prefer just to set a breakpoint in the debugger UI itself.

[gudvinr]

How about we add the c after the thb app_main as done in here ?

I don't have a solid opinion on that. It depends on what most users need (or what you think would be good default).

If it'd be the default with no options added I am fine with it since I don't use break on entry point that often and manual breakpoint is what I'd do anyway. This is usual behaviour for most debugging in non-embedded space so it doesn't seem like a big deal.

Another option is to make config parameter that controls adding c after thb app_main and I am fine with that either. OR make an option to append commands to initCommands. Then one could add c.

Another option is to make config parameter controlling adding thb app_main and then not breaking on entrypoint would be default and parameter would control adding thb app_main (or not add c) to initCommands.
Similarly, default initCommands may omit thb app_main and if user needs that, option that appends commands can be used to extend initCommands.

All in all, any of these will be fine as long as it is documented.

[brianignacio5]

I've made these changes in #1261

You can try these changes using this vsix installer to see if it works for you. Same for the trailing comma issue here.

[gudvinr]

You can try these changes using this vsix installer to see if it works for you.

Doesn't seem to be working. App still stopping on app_main. And I don't have custom initCommands.

Extension is updated though, because I don't see an issue with trailing comma anymore.

[gudvinr]

I do see that it's trying to continue though, so command itself gets executed:

JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
[esp32s3.cpu0] requesting target halt and executing a soft reset
[esp32s3.cpu0] Debug controller was reset.
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
[esp32s3.cpu1] requesting target halt and executing a soft reset
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Debug controller was reset.
[esp32s3.cpu1] Core was reset.
[esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Reset cause (3) - (Software core reset)
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
maintenance flush register-cache
Register cache flushed.
thb app_main
Hardware assisted breakpoint 1 at 0x420114a5: file main.cpp, line 24.
GDB unhandled notify: breakpoint-created: {"bkpt":{"number":"1","type":"hw breakpoint","disp":"del","enabled":"y","addr":"0x420114a5","func":"app_main()","file":"main.cpp","fullname":"main.cpp","line":"24","thread-groups":["i1"],"times":"0","original-location":"app_main"}}
c
Continuing.
[esp32s3.cpu0] Target halted, PC=0x420114A5, debug_reason=00000001
Set GDB target to 'esp32s3.cpu0'
[esp32s3.cpu1] Target halted, PC=0x40381648, debug_reason=00000000
[New Thread 1070304356]
[Remote target exited]
[New Thread 1070308764]
[New Thread 1070306560]
[New Thread 1070290364]
[New Thread 1070294808]
[New Thread 1070288480]
[Switching to Thread 1070304356]

Thread 2 "main" hit Temporary breakpoint 1, app_main () at main.cpp:24
24      ESP_ERROR_CHECK(nvs_flash_init());

There is some warning though but I don't know if it has any relevance:

GDB unhandled notify: breakpoint-created: {"bkpt":{"number":"1","type":"hw breakpoint","disp":"del","enabled":"y","addr":"0x420114a5","func":"app_main()","file":"main.cpp","fullname":"main.cpp","line":"24","thread-groups":["i1"],"times":"0","original-location":"app_main"}}

[brianignacio5]

@gudvinr Can you try this vsix installer ?

Setting "initialBreakpoint" : "" should ignore the initial breakpoint.

[gudvinr]

@gudvinr Can you try this vsix installer ?

Seems to be working. According to logs, maintenance flush register-cache is the latest command executed.

[gudvinr]

Thanks, much appreciated

[brianignacio5]

If you find the extension useful. Please leave us a review in the Visual Studio Code Marketplace