0

我正在尝试开始使用 microsoft 的 azure sphere 开发。

当我尝试在 vs 代码中调试任何启动项目时，它告诉我我在应用程序的第一行设置了一个断点。但是，vs 代码在“断点”选项卡中没有显示任何断点。

我在 Windows 10 上使用 Azure Sphere Extension 20.1 运行最新的 VS 代码版本（1.44）。Linux 上出现同样的问题。

要重现错误：

  1. 从 github 下载入门项目
  2. 为 Visual Studio 代码安装 Azure Sphere 扩展。
  3. azure-sphere-samples\Samples\HelloWorld\HelloWorld_HighLevelApp在 Visual Studio 代码中打开 HelloWorld_HighLevelApp 文件夹。
  4. 转到调试选项卡并点击左上角的绿色播放按钮。在按钮旁边应该说Launch for Azure Sphere High-Level Applications (gdb)

对我来说这不是错误，但输出控制台显示：

Deploying image...
Starting debugger....

Process /mnt/apps/1689d8b2-c835-2e27-27ad-e894d6d15fa9/bin/app created; pid = 2233
Listening on port 2345

Remote debugging from host 192.168.35.1, port 54911

Starting CMake Hello World application...

调试控制台显示：

...
Breakpoint 1, main () at ../../main.c:45
45  {
Loaded 'target:/usr/lib/libapplibs.so.0'. Symbols loaded.
Loaded 'target:/lib/libgcc_s.so.1'. Symbols loaded.
Loaded 'target:/usr/lib/libc++runtime.so.1'. Symbols loaded.

是否有解决该问题的方法/计划？

补充1：为了提供额外的说明，这里是一个截图，显示了控制台输出（断点设置）和ui（没有设置断点）的匹配失败 在此处输入图像描述

4

2 回答 2

1

Azure Sphere 使用 gdbserver 为设备提供调试通道。gdb 的默认行为是在进入 main 时中断。这对于那些期望运行到断点行为的 Windows 用户可能会感到困惑，这在 Visual Studio 中很常见。对于我们与 GDB 的接口，我们故意在 Visual Studio 中输入 main 时忽略断点以保持一致。您实际上可以在调试日志输出窗口中看到该断点被跳过。

对于 VS Code，当您在 Windows 上时，我们也会跳过 main 上的断点。从上面的输出来看，您似乎在 Linux 上。我已经有几个星期没有在 Linux 上使用它了，所以不记得那里的行为是否有意不同。在 Linux 上进入 main 时对我来说是有意义的，因为这是使用 GDB 时的普遍期望，这比在 Windows 上更常见。我会检查这是否是设计使然并回复，但我怀疑它是。

于 2020-04-09T15:39:25.737 回答
0

解决方案：

最后我找到了问题的根本原因。与纯 c 代码相比，调试 sphere 设备时，Visual Studio 代码的行为略有不同。

当您启动调试模式并且您最初没有设置断点时，在您设置断点之前它不会开始运行您的程序。在纯 c 调试中，程序只是运行，打印值显示在调试控制台中。

于 2020-04-14T07:42:43.647 回答