Debugging shared library, breakpoint problems

[Chris_Kay]

Hi, I hope you don't mind a bit of a double post from the LabVIEW software discussion forum.

I'm going from a Windows 10 host to a cRIO-9035 target, using LabVIEW 2017 with Realtime Module.  What I'd like to do is debug a shared library I created.

Using Eclipse and GDB, I can create the shared library, I can invoke the shared library on the cRIO from my VIs, and if a problem within the shared library causes a SIGSEGV while GDB is attached, I get control and can walk the stack, look at variables, etc.  I'm confident the library is running on the target and has debugging information.

While GDB is attached, I can see that what happens is that when the connection is started, Eclipse sends the "file" command to gdb.  It won't start without having a valid file.  gdb will load the symbols from my shared library, which are all offsets from the base and thus very low in memory.  Later, when my VI is loaded, LabVIEW will open my shared library and gdb will load the symbol table again, this time with the proper memory locations.

Therefore, "b <function name>" returns an error like "cannot access memory address 0xb40".  "info line <function name>" will return two entries.  "maintenance print symtab" will show that two symbol table objects are in memory and both are from the same object file.

In order to get this to work, I needed to run "file" to clear out all the symbols and then "sharedlibrary" to add symbols for the libraries in memory again, then it worked fine.

Is the workaround to put an empty file and then sharedlibrary in my .gdbinit?  It seems kind of silly to need to do that.

[BradM]

Debug Shared Libraries on Linux Real-Time Targets Using Eclipse/GDB gives some tips and tricks for making this flow a bit easier. Basically, using the pid of the running LVRT runtime engine to replace the need to provide a "file" to use (it will instead use the binary for lvrt, the LV RT runtime engine) to provide the basis for addresses and loaded libraries will avoid the low-address issues you're running into attempting to directly use the library as the debuggable entity. If the library is not already loaded, that's where the breakpoint pending on configuration comes into play.

[Chris_Kay]

---

@BradM wrote:

Debug Shared Libraries on Linux Real-Time Targets Using Eclipse/GDB gives some tips and tricks for making this flow a bit easier. Basically, using the pid of the running LVRT runtime engine to replace the need to provide a "file" to use (it will instead use the binary for lvrt, the LV RT runtime engine) to provide the basis for addresses and loaded libraries will avoid the low-address issues you're running into attempting to directly use the library as the debuggable entity. If the library is not already loaded, that's where the breakpoint pending on configuration comes into play.

---

Thank you for the quick response.  I tried to follow those instructions, but Eclipse/GDB still would not launch a debugging session without a binary being specified as the target in the Debug configuration (the C/C++ application).

I'm attached to the lvrt process, but Eclipse still wants to know which binary I'm debugging.

Something that may be related, I'm using the 2017 tools and there's no option for the standard remote create process launcher.  There's automatic, manual, and legacy.  Could that be related?

[Chris_Kay]

Also, at Integrating C Code with LabVIEW on NI Linux Real-Time Targets, NI shows a screenshot where the shared library is set as the C/C++ application to be debugged, and the shared library's location on the target system as the Remote Absolute Path for C/C++ Application.

The section on command-line debugging also says to give the file command the gdb.

[BradM]

Chris_Kay,

One thing you could do is to copy over the lvrt binary itself, point Eclipse to that to use as the file to debug (ultimately, that's what you're attaching to on the target). You'd ideally want to have the remote filesystem (or at least a subset including /lib, /usr/lib, and /usr/local/natinst/) present locally on the debug machine (or accessible over a network filesystem mount, e.g. using either Samba on the RT target or installing something to allow access to SFTP shares on Windows as a network share)

I'd have to dig around the newer tools, but I would expect that the option still exists, I'd check to see if it exists under the Manual option.

As for the documentation you pointed to, it sadly is a bit misleading. As soon as you define the remote command to attach to a running process, it will replace the notion of the "file" with the actual file that represents that running process.

[Chris_Kay · Accepted solution]

It's been a while, here's what I ended up doing.  I set Eclipse to debug a different shared library.  I still attached to lvrt and had breakpoints set for the shared library I was really debugging.  That worked cleanly and avoided the low address issues.