Are there PDB files available for TDxNavLib.lib?

[pelle]

When linking using Visual Studio on Windows, we get this warning:

Code: Select all

warning LNK4099: PDB '' was not found with 'TDxNavLib.lib(navlib_stub.obj)' or at ''; linking object as if no debug info

We can of course suppress the warning for the entire project, but then we wouldn't notice if other PDB files are missing. It would be nicer to have the actual PDB file(s). Could it be bundled with the SDK, or is it secret?

Cheers,
Pelle

[ngomes]

Could it be bundled with the SDK, or is it secret?

Alas, no. 3Dconnexion does not include pdb files in SDK packages.

[pelle]

I still don't understand why 3Dconnexion ships their release libraries with references to debug information, but if you'd like to remove them on your end and thus avoid the linker warnings, I thought I'd share a way. (Ofc, do it at your own risk.)

Code: Select all

lib /list TDxNavLib.lib
lib /extract:navlib_load.obj TDxNavLib.lib
lib /extract:navlib_stub.obj TDxNavLib.lib
llvm-objcopy --remove-section .debug$T navlib_load.obj
llvm-objcopy --remove-section .debug$T navlib_stub.obj
lib /out:TDxNavLib_stripped.lib *.obj

"lib" is a tool shipped with Visual Studio, so run this from a Visual Studio Developer Prompt. "llvm-objcopy" ships with LLVM.

[ngomes]

I still don't understand why 3Dconnexion ships their release libraries with references to debug information,

Post-morten analysis. The PDB files are invaluable to review code that fails in production.

[pelle]

I still don't understand why 3Dconnexion ships their release libraries with references to debug information,

Post-morten analysis. The PDB files are invaluable to review code that fails in production.

Yes, the PDB files are invaluable, and of course 3Dconnexion needs to retain them internally. I'm not questioning that.

However, given that they are internal, no external user will ever be able to do any symbol-aware post-mortem analysis. So, what I am questioning here is the reference to the PDB files embedded in the production lib file given to external users. It makes my linker complain, and I can't tell it to treat warnings as errors.

If the debug information was stripped out from the lib, my linker wouldn't complain. If I then have a crash, I can still send in my dump file and they can do the post-mortem analysis with the original lib file (the one containing the PDB reference).

[ngomes]

what I am questioning here is the reference to the PDB files embedded in the production lib file given to external users. It makes my linker complain, and I can't tell it to treat warnings as errors.

The warnings are unfortunate, I agree.

We did look at stripping the debug section (very similar approach to what you suggested before) but it seemed to affected how the debugger would find the symbols (match the binary with the pdb file). Do you have any information on that?

[pelle]

We did look at stripping the debug section (very similar approach to what you suggested before) but it seemed to affected how the debugger would find the symbols (match the binary with the pdb file). Do you have any information on that?

I'm unfortunately not read up on this, but, it sounds right that a removal would affect the debugger.

I guess the simplest solution would be to keep your existing work flows internally, and to only remove the debug sections in an automated stage prior to public distribution. The same stage MUST then preserve a pre-strip copy, so that you have that readily available if a dump comes in for analysis.

(Another option would be to fabricate the stripped debug sections when you need them, but that seems tedious. )

[ngomes]

As back then, we're reluctant to do it without more definite information.

We do agree (it's most definitely not just me) that those warnings are annoying and especially aggravating since they cannot be disabled.

I will consider taking action to work around the issue but we need to have more definite information to ensure it does not affect the memdump analysis we get from the field.

[pelle]

As back then, we're reluctant to do it without more definite information.

We do agree (it's most definitely not just me) that those warnings are annoying and especially aggravating since they cannot be disabled.

I will consider taking action to work around the issue but we need to have more definite information to ensure it does not affect the memdump analysis we get from the field.

Oh, I thought you were referring to how the debugger would find the information. Let's break it up:

- When it comes to removal of the Debug$T section, I'm certain you can still get and analyze memory dumps. But you probably shouldn't trust a random dude on the Internet though; instead, check e.g. https://learn.microsoft.com/en-us/windo ... /pe-format .

- When it comes to how to analyze memory dumps, I don't know if you can someone provide the PDB information "on the side", when the lib file doesn't contain it. But if you keep the original lib file (with an intact Debug$T section), you won't have to provide it on the side.