From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Debugging Shared Library on NI Linux (gdb symbol resolution)

Hi, I'm hoping someone can help me out with an odd situation I encountered.

 

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.

 

My problem is that I can't set breakpoints.  What I think is happening is that my shared library has both symbol table and dynamic symbols ELF sections.  The symbol table is loaded with the offsets from the library's base.

 

So what happens is that when I try to set a breakpoint based on a function in my library or a location in my file, instead of GDB setting a breakpoint in the space it should be based in 'info sharedlibrary', it tries to set a breakpoint to an extremely low address (such as 0xb4).  If I look at 'info symbol 0xb4' or 'info symbol <memory start from sharedlibrary output + 0xb4>', I get the same symbol returned.

 

When I poked at some other shared libraries on the target, which readelf showed had no symbol table but did have dynamic symbols, they referred to the location I expected (within the shared library's memory space).

 

Is there a way to get GDB to use a base with my shared library symbols as offsets?  Is it a manual command or can GDB do it automatically?

 

Thank you very much!

0 Kudos
Message 1 of 1
(2,136 Views)