Issue with debugging linked C code

embedded
1

I'm new to rust and the ecosystem and I have a bunch of C Libraries that I would to be able to call from my new rust project. Everything runs fine and I was able to link the archive file and call the function. However if the program goes over a call to C the debugger dies essentially.

I have a baremetal cortex processor that I am programming over jtag and then just using the debugger in vscode to connect to it.

Tools:
-vscode
-rust-analyzer extension
-native debug extension
-gnu tools (for gdb)

My launch.json looks similar to this:

"version": "0.2.0",
"configurations": [
    {
        "name": "Remote debug",
        "type": "gdb",
        "request": "launch",
        "cwd": "${workspaceRoot}",
        "executable": "${workspaceRoot}/target/armv7r-none-eabi/debug/hello_world", 
        "gdbpath" : "arm-none-eabi-gdb",
        "target" : "extended-remote localhost:3000
    }
]

Is there a different debugger I should be using? Is there something I should be changing in the launch file?

Any ideas would be helpful.

2

do you mean the "step-over" debugging command? did the C function crash the program? or it's just the debugger?

if the program didn't crash, but you cannot "step-over" the call, what happens if you set a break point after the call to the ffi function, and use "continue" instead of "step-over"?

also, even if it failed to "step-over" the call, you should still be able to "step-in" into the function, unless the call instruction itself is faulty, which indicates UB and your ffi usage is unsound.

1 Like
3

Apologies I was writing this in a hurry. What I mean is that the rust code will break, step-into, step-over and run perfect fine. However if at any time the code would have executed the C code the debugger will not work. This means if the debugger is already attached does the "step-over" command or "step-into" the debugger crashes, and also if I were to run past it. If the code already executed that line and then I attach my debugger it will not attach properly.

I did however completely ignore the GDB error which states:
"Warning: could not covert 'main' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report"

And my immediate search of this shows other people have had similar issues, but I don't see anyone with a fix for it. Seems less like an issue with the code (not ruling that out yet) and more of an issue with how my arm-none-eabi-gdb is working.

4

it sounds like a call to an invalid function address to me. are you able to step-in in assembly code? if not, when it stops at the call instruction, can you examine the target address of the call?

sounds like the processor is faulted, perhaps a hard fault, but it's strange the debugger didn't capture the exception. normally, a debugger should be able to intercept any fault or trap. do you have the exception handler setup correctly? try set a break point at the exception handler.

I have not seen this message before, I guess it's referring to the debug symbol names?

5

Okay so I did more debugging and it looks like I have narrowed down the issue. The code does seem to be executing perfectly fine. If I don't ever attach the debugger in VScode the code is actually running and I have a system for sending and receiving commands and they work just fine.

I then tried to run GDB on command line and it has no issue. I am able to debug, and step over any line of code just fine. It is the VScode extension that is causing the issue. My guess it's Native Debug or possibly VScode its self is not handling the debug code that has been received.

6

you can try out the probe-rs debugger. here's an example of it in action from the website: