An IDL system routine is an IDL procedure or function that is written in a compiled language with an IDL specific interface and linked into IDL, instead of being written in the IDL language itself. The best way to create an IDL system routine is to compile and link the routine into a sharable library and then to add the routine to IDL at runtime using either the LINKIMAGE procedure or by making your routines part of a Dynamically Loadable Module (DLM).
Note: We recommend the use of Dynamically Loadable Modules rather than LINKIMAGE whenever possible.
Debugging System Routines
To debug system routines and DLMs, you must attach your debugger to the IDL process that is running your library code. In IDL 8.0 and later, the process to which you should attach the debugger varies depending the application which is running IDL and the platform.
The following table details which executable to attach to for IDL 9.2:
| Main Application
| Platform
| IDL Executable
|
| IDL Command Line |
Linux and Mac |
idl |
| Windows |
idl_machine.exe |
| IDL Workbench |
Linux and Mac |
idl_engine |
| Windows |
idl_engine.exe |
| IDL Extension for VS Code |
Linux and Mac |
idl_machine |
| Windows |
idl_machine.exe |
| IDL_IDLBridge |
Linux and Mac |
idl_opserver |
| Windows |
idl_opserver.exe |
| IDL Runtime |
Linux and Mac |
idl |
| Windows |
idlrt.exe |
| Task Engine |
Linux and Mac |
taskengine |
| Windows |
taskengine.exe |
The process that runs IDL may be a child process of the main application. For example, in the case of the Windows IDL workbench, the parent process is "idlde.exe" while the process that is actually running IDL is "idl_engine.exe". In all cases, the process that runs IDL links to the IDL library, which contains the parser, interpreter, executive, etc.
Debugging Tools
The following table lists some tools for debugging and examining processes.
| Platform
| Debuggers
| Other Tools
|
| Linux |
gdb, VS Code |
Use "pstack" or "gstack" get the call stack of a process. Use "lsof" to get a list of open files. Use "ldd" to see what shared libraries are used. |
| Mac |
lldb, VS Code, Xcode |
Use "Activity Monitor" to get a process' list open files and snapshots of call stacks. Use the "Console" application to get crash reports. Use "otool -L <object-file>" to see what shared libraries the object uses. |
| Windows |
Visual Studio, VS Code |
Consider "WinDbg" for debugging. |
Mac and Code Signing
On Mac, the IDL executables and libraries are code signed and hence debuggers cannot readily attach. The following example shows the error one might get:
% cd /Users/<user>/Applications/NV5/idl92/bin/bin.darwin.arm64
% lldb ./idl
(lldb) target create "./idl"
Current executable set to '/Users/<user>/Applications/NV5/idl92/bin/bin.darwin.arm64/idl' (arm64).
(lldb) run
error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))
(lldb)
To give lldb permission to attach to IDL, run the following command:
% codesign --force -s - ./idl
Note that the Xcode command line utilities may need to be installed to get the codesign utility.