weixin_39785286
weixin_39785286
2020-12-27 06:43

Debugging

What is the recommended solution for debugging the Azure IoT gateway? I have an example running on a Raspberry Pi. Ideally we would like to develop and debug via Visual Studio on a windows platform. I have tried for some time to make this work with Microsoft VC_Linux cross platform tools but does not work well with a project that already exists.
We would appreciate guidance on debugging in the documentation and perhaps a VC_Linux VS project included in the source.

该提问来源于开源项目:Azure/iot-edge-v1

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

6条回答

  • weixin_39599081 weixin_39599081 4月前

    To unblock you now though there's a workaround you can implement to debug libble.so (or any other SO that is linked at runtime via dlopen). The workaround involves:

    1. Explicit linking with the runtime linked library
    2. Configure the linker to not ignore linked libraries if symbols from it are not used (which is the case when using runtime linking)

    For the BLE module for instance, you'd do the following:

    1. Modify line 94 of modules/ble/CMakeLists.txt to change the library type from MODULE to SHARED.
    2. Modify line 25 of samples/ble_gateway/CMakeLists.txt to additionally link with ble and add a CMake instruction to modify linker settings. Here's what it should look like:
    
    set(LIBS ${LIBS} gateway ble)
    set(CMAKE_EXE_LINKER_FLAGS  "-Wl,--no-as-needed ${CMAKE_EXE_LINKER_FLAGS}")
    

    Now build everything and then if you run readelf -d build/samples/ble_gateway/ble_gateway you should see that libble.so is now listed as one of the NEEDED libraries. When you run the sample though it will still not know where to find this file on the file system. One way to address that is to setup the environment variable LD_LIBRARY_PATH to point to where libble.so lives. Like so:

    
    export LD_LIBRARY_PATH=/code/azure-iot-gateway-sdk/build/modules/ble
    

    I added this statement to the Pre-Launch Command setting in the Debugging tab of the project properties dialog in Visual Studio.

    image

    This will cause VS to run that command before every debug run. Now you should be able to set breakpoints in the BLE module implementation sources and those should be hit.

    点赞 评论 复制链接分享
  • weixin_39524959 weixin_39524959 4月前

    This question seems to have been answered. Not much activity lately, so I'll close this. Please reopen if needed.

    点赞 评论 复制链接分享
  • weixin_39599081 weixin_39599081 4月前

    I have had success remote debugging the gateway on a Pi from Visual Studio 2015. I was able to do this by using the Makefile project template (search for "Makefile Project Template" in this blog post). This template allows you to take control of what it means to "build", "clean" and "rebuild" by specifying the commands to run. In the case of the gateway you'd specify make -j $(nproc), make clean and make clean && make -j $(nproc) respectively.

    You'll want to manually get an initial build ready by SSHing on to the Pi first before you set this up in VS. As for the source files you can simply add them to your VS solution on Windows and set breakpoints and so forth.

    Also, please take note of the details mentioned in the blog post regarding additional debugger commands you need to specify (handle SIGILL nostop noprint) to gdb to cause it to ignore the initial "illegal instruction" error that it throws when debugging targets on an ARM device. Good luck!

    点赞 评论 复制链接分享
  • weixin_39785286 weixin_39785286 4月前

    Thanks, I can get so far with this. I can now start a debug session and hit a breakpoint at main, but VS is unable to set a breakpoint on functions such as BLEIO_gatt_connect() in ble_gatt_io_linux_connect.c.

    It appears that symbol information in missing in the linux build as it was in the windows build.

    How can debug information be restored for files in the module libraries (in this case libble.so)?

    点赞 评论 复制链接分享
  • weixin_39599081 weixin_39599081 4月前

    I tried reproducing this and I encountered the same issue. I am able to set breakpoints and debug when I directly run gdb on the Pi but Visual Studio does not seem able to do the same. I also tried debugging on an x64 Linux VM and had the same result. From what I can tell Visual Studio remote debugging for Linux appears unable to detect dynamic SO loads via dlopen syscalls. I stepped in to the point where the gateway loads the BLE SO and noticed that though the call returns a non-NULL value VS's modules window did not list the newly loaded SO. It only lists the SOs that are loaded automatically when the main executable is loaded. I'll see if I can get some additional context from the VS folks who work on this.

    点赞 评论 复制链接分享
  • weixin_39599081 weixin_39599081 4月前

    To confirm this I wrote a small test case program and found the same behavior. If I try to step into a function that has been loaded via dlopen and dlsym it segfaults. Will check with the VS team and let you know.

    点赞 评论 复制链接分享

相关推荐