How to check if LLDB loaded debug symbols from shared libraries? - c++

On Linux I use
(gdb) i shared
in gdb and gdb prints a list of libraries either with a star * if no debug symbols are loaded or without it if loaded, e.g:
0x0000000100c18660 0x0000000100c489a0 Yes (*) /Users/anon/work/software/webrtc-audio-processing-0.1/build_darwin/../bin/darwin/lib/libwebrtc_audio_processing.0.dylib
0x0000000100c57ca0 0x0000000100c76978 Yes /Users/anon/work/software/speex/speex/speex-1.2rc2/build_darwin/../bin/darwin/lib/libspeex.1.dylib
I found that in LLDB I should use
(lldb) image list
to do the same. But I get a list of libraries which says nothing to me on whether debug symbols are loaded for the lib or not, e.g:
[181] 19269C1D-EB29-384A-83F3-7DDDEB7D9DAD 0x00007fff8d2d3000 /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi
[182] 8D7BA9BA-EB36-307A-9119-0B3D9732C953 0x00007fff879ee000 /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth
[183] 6F03761D-7C3A-3C80-8031-AA1C1AD7C706 0x00007fff92e52000 /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
So how do I check if debug symbols are loaded by LLDB?
UPDATE: I just decided to post output of (lldb) image lookup -vn <function> (thanks Jim) for others to know what it looks like:
image lookup -vn Herqq::Upnp::HSsdp::init
2 matches found in libHUpnp.2.dylib:
Address: libHUpnp.2.dylib[0x00000000000283f0] (libHUpnp.2.dylib.__TEXT.__text + 150384)
Summary: libHUpnp.2.dylib`Herqq::Upnp::HSsdp::init() at hssdp.cpp:804
Module: file = "libHUpnp.2.dylib", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "/Users/blade/work/software/HUPnP/build-herqq-Desktop_Qt_5_5_0_clang_64bit-Debug/hupnp/../../herqq/hupnp/src/ssdp/hssdp.cpp", language = "c89"
Function: id = {0xa0002401f}, name = "init", range = [0x00000000000283f0-0x0000000000028511)
FuncType: id = {0xa0002401f}, decl = hssdp.h:304, clang_type = "_Bool (void)"
Blocks: id = {0xa0002401f}, range = [0x000283f0-0x00028511)
LineEntry: [0x00000000000283f0-0x00000000000283ff): /Users/blade/work/software/HUPnP/build-herqq-Desktop_Qt_5_5_0_clang_64bit-Debug/hupnp/../../herqq/hupnp/src/ssdp/hssdp.cpp:804
Symbol: id = {0x00000c9b}, range = [0x00000000000283f0-0x0000000000028520), name="Herqq::Upnp::HSsdp::init()", mangled="_ZN5Herqq4Upnp5HSsdp4initEv"
Variable: id = {0xa0002403a}, name = "this", type= "Herqq::Upnp::HSsdp *", location = DW_OP_fbreg(-16), decl =
Variable: id = {0xa00024047}, name = "herqqLog__", type= "HLogger", location = DW_OP_fbreg(-32), decl = hssdp.cpp:805
Variable: id = {0xa00024056}, name = "ha", type= "QHostAddress", location = DW_OP_fbreg(-56), decl = hssdp.cpp:812
Address: libHUpnp.2.dylib[0x0000000000028550] (libHUpnp.2.dylib.__TEXT.__text + 150736)
Summary: libHUpnp.2.dylib`Herqq::Upnp::HSsdp::init(QHostAddress const&) at hssdp.cpp:817
Module: file = "libHUpnp.2.dylib", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "/Users/blade/work/software/HUPnP/build-herqq-Desktop_Qt_5_5_0_clang_64bit-Debug/hupnp/../../herqq/hupnp/src/ssdp/hssdp.cpp", language = "ISO C++:1998"
Function: id = {0xa0002408f}, name = "init", range = [0x0000000000028550-0x000000000002862d)
FuncType: id = {0xa0002408f}, decl = hssdp.h:321, clang_type = "_Bool (const class QHostAddress &)"
Blocks: id = {0xa0002408f}, range = [0x00028550-0x0002862d)
LineEntry: [0x0000000000028550-0x0000000000028564): /Users/blade/work/software/HUPnP/build-herqq-Desktop_Qt_5_5_0_clang_64bit-Debug/hupnp/../../herqq/hupnp/src/ssdp/hssdp.cpp:817
Symbol: id = {0x00000ca3}, range = [0x0000000000028550-0x0000000000028630), name="Herqq::Upnp::HSsdp::init(QHostAddress const&)", mangled="_ZN5Herqq4Upnp5HSsdp4initERK12QHostAddress"
Variable: id = {0xa000240aa}, name = "this", type= "Herqq::Upnp::HSsdp *", location = DW_OP_fbreg(-16), decl =
Variable: id = {0xa000240b7}, name = "unicastAddress", type= "const QHostAddress &", location = DW_OP_fbreg(-24), decl = hssdp.cpp:816
Variable: id = {0xa000240c6}, name = "herqqLog__", type= "HLogger", location = DW_OP_fbreg(-40), decl = hssdp.cpp:818

If your binary was built with a dSYM, then the dSYM will show up on the line after the binary's listing in image list.
There isn't an easy way to do this if the binary is using the "leave the debug information in the .o file" style which is the default for the Debug configuration in Xcode. I filed a bug to make that easier to see.
One fairly simple way to do it is:
(lldb) image lookup -vn <SomeFunctionNameThatShouldHaveDebugInfo>
If the output of that command includes a CompileUnit, then the .o file containing that function has debug information, otherwise, not.

Related

collector_value Error while Rendering RMarkdown

Yesterday, I rendered the following code in an RMarkdown file:
trip_data_202208 <- read_csv(("/Users/mif06/Documents/
Cyclistic/CSV/202208_divvy_tripdata.csv"),
col_types = cols_only(ride_id = col_character(),
rideable_type = col_character(), started_at = col_character(),
ended_at = col_character(),
total_ride_time = col_time(format = ""),
day_of_week = col_character(),
start_station_name = col_character(),
start_station_id = col_character(),
end_station_name = col_character(),
end_station_id = col_character(),
start_lat = col_double(),
start_lng = col_double(), end_lat = col_double(),
end_lng = col_double(),member_casual = col_character()
)
)
Today, I go back to add to the RMarkdown file and I get the following error message:
Error in UseMethod("collector_value") :
no applicable method for 'collector_value' applied to an object of class "c('collector_skip', 'collector')"
I'm not sure why I'm having an issue since I rendered the same code before.
I can't even find what this error means. Thank you for your help!

lldb source paths for an external framework

I've made a small WebRTC player on macOS that is linked against Googles libwebrtc to torubleshoot my WebRTC streaming backend. But I am having issues putting any breakpoints in libwebrtc. For example, if I set a breakpoint in a known file like this breakpoint set --file packet_buffer.cc --line 365, lldb seems to resolve the symbol since the output from lldb is:
Breakpoint 1: where = WebRTC`webrtc::video_coding::PacketBuffer::FindFrames(unsigned short) + 1827 at packet_buffer.cc:365:11, address = 0x0000000101331183
But when the breakpoint is hit, Xcode shows disassembly:
The thing that troubles me is the relative path of the source - I am unsure to where Xcode/lldb resolves that - to the root of the loaded application or the module?
If I do a image lookup with a function from that file, e.g. image lookup -vn webrtc::video_coding::PacketBuffer::Packet::Packet, the output shows that lldb seems to find the symbol:
4 matches found in /Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC:
Address: WebRTC[0x0000000000f1b8d0] (WebRTC.__TEXT.__text + 15835536)
Summary: WebRTC`webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long) at packet_buffer.cc:58
Module: file = "/Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "../../modules/video_coding/packet_buffer.cc", language = "c++14"
Function: id = {0x4d30002c9f3}, name = "webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long)", mangled = "_ZN6webrtc12video_coding12PacketBuffer6PacketC2ERKNS_17RtpPacketReceivedERKNS_14RTPVideoHeaderExx", range = [0x000000010132e8d0-0x000000010132ea72)
FuncType: id = {0x4d30002c9f3}, byte-size = 0, decl = packet_buffer.h:38, compiler_type = "void (const class webrtc::RtpPacketReceived &, const struct webrtc::RTPVideoHeader &, int64_t, int64_t)"
Blocks: id = {0x4d30002c9f3}, range = [0x10132e8d0-0x10132ea72)
LineEntry: [0x000000010132e8d0-0x000000010132e901): ../../modules/video_coding/packet_buffer.cc:58
Symbol: id = {0x00057dfa}, range = [0x000000010132e8d0-0x000000010132ea80), name="webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long)", mangled="_ZN6webrtc12video_coding12PacketBuffer6PacketC2ERKNS_17RtpPacketReceivedERKNS_14RTPVideoHeaderExx"
Variable: id = {0x4d30002ca11}, name = "this", type = "webrtc::video_coding::PacketBuffer::Packet *", location = DW_OP_fbreg(-80), decl =
Variable: id = {0x4d30002ca1f}, name = "rtp_packet", type = "const webrtc::RtpPacketReceived &", location = DW_OP_fbreg(-88), decl = packet_buffer.cc:42
Variable: id = {0x4d30002ca2e}, name = "video_header", type = "const webrtc::RTPVideoHeader &", location = DW_OP_fbreg(-96), decl = packet_buffer.cc:43
Variable: id = {0x4d30002ca3d}, name = "ntp_time_ms", type = "int64_t", location = DW_OP_fbreg(-104), decl = packet_buffer.cc:44
Variable: id = {0x4d30002ca4c}, name = "receive_time_ms", type = "int64_t", location = DW_OP_fbreg(-112), decl = packet_buffer.cc:45
Address: WebRTC[0x0000000000f1ba80] (WebRTC.__TEXT.__text + 15835968)
Summary: WebRTC`webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long) at packet_buffer.cc:58
Module: file = "/Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "../../modules/video_coding/packet_buffer.cc", language = "c++14"
Function: id = {0x4d30002cbf0}, name = "webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long)", mangled = "_ZN6webrtc12video_coding12PacketBuffer6PacketC1ERKNS_17RtpPacketReceivedERKNS_14RTPVideoHeaderExx", range = [0x000000010132ea80-0x000000010132eabb)
FuncType: id = {0x4d30002cbf0}, byte-size = 0, decl = packet_buffer.h:38, compiler_type = "void (const class webrtc::RtpPacketReceived &, const struct webrtc::RTPVideoHeader &, int64_t, int64_t)"
Blocks: id = {0x4d30002cbf0}, range = [0x10132ea80-0x10132eabb)
LineEntry: [0x000000010132ea80-0x000000010132eaa0): ../../modules/video_coding/packet_buffer.cc:58
Symbol: id = {0x00057dfe}, range = [0x000000010132ea80-0x000000010132eac0), name="webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long)", mangled="_ZN6webrtc12video_coding12PacketBuffer6PacketC1ERKNS_17RtpPacketReceivedERKNS_14RTPVideoHeaderExx"
Variable: id = {0x4d30002cc0e}, name = "this", type = "webrtc::video_coding::PacketBuffer::Packet *", location = DW_OP_fbreg(-8), decl =
Variable: id = {0x4d30002cc1b}, name = "rtp_packet", type = "const webrtc::RtpPacketReceived &", location = DW_OP_fbreg(-16), decl = packet_buffer.cc:42
Variable: id = {0x4d30002cc29}, name = "video_header", type = "const webrtc::RTPVideoHeader &", location = DW_OP_fbreg(-24), decl = packet_buffer.cc:43
Variable: id = {0x4d30002cc37}, name = "ntp_time_ms", type = "int64_t", location = DW_OP_fbreg(-32), decl = packet_buffer.cc:44
Variable: id = {0x4d30002cc45}, name = "receive_time_ms", type = "int64_t", location = DW_OP_fbreg(-40), decl = packet_buffer.cc:45
Address: WebRTC[0x0000000000f23740] (WebRTC.__TEXT.__text + 15867904)
Summary: WebRTC`webrtc::video_coding::PacketBuffer::Packet::Packet() at packet_buffer.h:37
Module: file = "/Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "../../modules/video_coding/packet_buffer.cc", language = "c++14"
Function: id = {0x4d300038648}, name = "webrtc::video_coding::PacketBuffer::Packet::Packet()", mangled = "_ZN6webrtc12video_coding12PacketBuffer6PacketC1Ev", range = [0x0000000101336740-0x000000010133675b)
FuncType: id = {0x4d300038648}, byte-size = 0, decl = packet_buffer.h:37, compiler_type = "void (void)"
Blocks: id = {0x4d300038648}, range = [0x101336740-0x10133675b)
LineEntry: [0x0000000101336740-0x0000000101336750): ../../modules/video_coding/packet_buffer.h:37
Symbol: id = {0x0005803a}, range = [0x0000000101336740-0x0000000101336760), name="webrtc::video_coding::PacketBuffer::Packet::Packet()", mangled="_ZN6webrtc12video_coding12PacketBuffer6PacketC1Ev"
Variable: id = {0x4d300038664}, name = "this", type = "webrtc::video_coding::PacketBuffer::Packet *", location = DW_OP_fbreg(-8), decl =
Address: WebRTC[0x0000000000f23760] (WebRTC.__TEXT.__text + 15867936)
Summary: WebRTC`webrtc::video_coding::PacketBuffer::Packet::Packet() at packet_buffer.h:37
Module: file = "/Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "../../modules/video_coding/packet_buffer.cc", language = "c++14"
Function: id = {0x4d300038672}, name = "webrtc::video_coding::PacketBuffer::Packet::Packet()", mangled = "_ZN6webrtc12video_coding12PacketBuffer6PacketC2Ev", range = [0x0000000101336760-0x00000001013367e3)
FuncType: id = {0x4d300038672}, byte-size = 0, decl = packet_buffer.h:37, compiler_type = "void (void)"
Blocks: id = {0x4d300038672}, range = [0x101336760-0x1013367e3)
LineEntry: [0x0000000101336760-0x0000000101336770): ../../modules/video_coding/packet_buffer.h:37
Symbol: id = {0x0005803e}, range = [0x0000000101336760-0x00000001013367f0), name="webrtc::video_coding::PacketBuffer::Packet::Packet()", mangled="_ZN6webrtc12video_coding12PacketBuffer6PacketC2Ev"
Variable: id = {0x4d30003868e}, name = "this", type = "webrtc::video_coding::PacketBuffer::Packet *", location = DW_OP_fbreg(-8), decl =
It seems weird that there are duplicate entries (and I have no idea why), but at least lldb seems to know the name. The other thing that worries me is the relative path in CompileUnit but I am not sure how to fix that (compile flags while building libwebrtc?). The relative path is not correct if you take the /Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/ as a base name, since then it should be ../../../modules, but maybe lldb treats frameworks differently and uses /Users/rudolfs/Git/webrtc-checkout/src/out/Debug as a base path?
I've seen multiple questions here regarding target.source-map, but I don't understand if this would help here and what should I override?
I also tried setting a custom working directory in the Xcode scheme (to /Users/rudolfs/Git/webrtc-checkout/src/out/Debug) in hope that the relative paths would not get resolved but that did not help.
The output of image lookup -v is showing 4 matches for this source line -- this method was inlined in four different places (the last two looking like a ctor).
Looking at the LineEntrys, lldb is trying to show the source at ../../modules/video_coding/packet_buffer.cc:58 or ../../modules/video_coding/packet_buffer.h:37.
This is going to be tricky for lldb to resolve. The compiler has created debug information with relative paths. I thought most compilers would try to come up with an absolute path to the location of the source files for the debug information, but it's been a while since I've looked into a problem like this. It may be that invoking your compiler with an absolute source pathname may work, if you're invoking it with a relative one right now.
A common problem is when the source was compiled on one computer in /build-dir but on your debug system the source is in /src-dir -- there's an lldb setting specifically for this case, target.source-map which remaps the file paths in the debug information when looking for the source at debug-time. But that's not going to help you here.
I encountered a similar problem. source-map config works for me. You can try map ../.. to /Users/rudolfs/Git/webrtc-checkout/src.

How to display full file name in lldb

I'm pretty familiar with the basic commands of gdb. Unfortunately Apple switched to lldb which has completely different set of commands and now I need to learn a new tool.
Trying to debug a program I step into the function, but it does not display a full file name where the function is. So no path to the file.
Is there a command to retrieve it?
Thank you.
You can do image lookup -n <func-name> to get the file name
(lldb) image lookup -n main
1 match found in /Users/ml9951/manticore/trunk/src/regression-tests/goals/seq-logging/a.out:
Address: a.out[0x0000000100027670] (a.out.__TEXT.__text + 156144)
Summary: a.out`main at main.c:90 <<--------
(lldb)
It doesn't have the entire path, but hopefully this helps some.
(lldb) image lookup -v -a $pc
Address: libjvm.so[0x0000000001a3c2c4] (libjvm.so.PT_LOAD[1]..text + 24588836)
Summary: libjvm.so`SystemDictionaryShared::add_lambda_proxy_class(InstanceKlass*, InstanceKlass*, Symbol*, Symbol*, Symbol*, Method*, Symbol*, JavaThread*) + 356 at systemDictionaryShared.cpp:1642:3
Module: file = "/home/foo/bar/jdk17u-git/build/linux-x86_64-server-fastdebug/images/jdk/lib/server/libjvm.so", arch = "x86_64"
CompileUnit: id = {0x0000038b}, file = "/home/foo/bar/jdk17u-git/src/hotspot/share/classfile/systemDictionaryShared.cpp", language = "c++14"
Function: id = {0x0d35d4df}, name = "SystemDictionaryShared::add_lambda_proxy_class(InstanceKlass*, InstanceKlass*, Symbol*, Symbol*, Symbol*, Method*, Symbol*, JavaThread*)", mangled = "_ZN22SystemDictionaryShared22add_lambda_proxy_classEP13InstanceKlassS1_P6SymbolS3_S3_P6MethodS3_P10JavaThread", range = [0x00007ffff74ff160-0x00007ffff74ff79d)
FuncType: id = {0x0d35d4df}, byte-size = 0, decl = systemDictionaryShared.cpp:1631:6, compiler_type = "void (class InstanceKlass *, class InstanceKlass *, class Symbol *, class Symbol *, class Symbol *, class Method *, class Symbol *, class JavaThread *)"
Blocks: id = {0x0d35d4df}, range = [0x7ffff74ff160-0x7ffff74ff79d)
LineEntry: [0x00007ffff74ff2c4-0x00007ffff74ff2c9): /home/foo/bar/jdk17u-git/src/hotspot/share/classfile/systemDictionaryShared.cpp:1642:3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Symbol: id = {0x000055ba}, range = [0x00007ffff74ff160-0x00007ffff74ff79d), name="SystemDictionaryShared::add_lambda_proxy_class(InstanceKlass*, InstanceKlass*, Symbol*, Symbol*, Symbol*, Method*, Symbol*, JavaThread*)", mangled="_ZN22SystemDictionaryShared22add_lambda_proxy_classEP13InstanceKlassS1_P6SymbolS3_S3_P6MethodS3_P10JavaThread"
Variable: id = {0x0d35d4fd}, name = "caller_ik", type = "InstanceKlass *", location = DW_OP_reg12 R12, decl = systemDictionaryShared.cpp:1631:68
Variable: id = {0x0d35d512}, name = "lambda_ik", type = "InstanceKlass *", location = DW_OP_reg3 RBX, decl = systemDictionaryShared.cpp:1632:68
...

How to configure Flume conf to parse source using regex_extractor

I am just starting out with Flume. Trying to figure out how to extract fields from source log files using the interceptor regex_extract. However, between the source and sink the log file does not seem to change regardless of what I set in the conf file. Anyone have any ideas? Just trying to go from 1,a,b,c in the source to 1 in the sink.
Source file is simply in a test structure of 1,a,b,c,d yet always outputs in spooldir2 as 1,a,b,c,d
a1.sources = fs1
a1.sinks = hdfs-sink
a1.channels = parse
a1.sources.fs1.type = spooldir
a1.sources.fs1.spoolDir = /tmp/spooldir
a1.sources.fs1.fileHeader = true
a1.sources.fs1.interceptors = i1
a1.sources.fs1.interceptors.i1.type = regex_extractor
a1.sources.fs1.interceptors.i1.regex = ^(\\d)
a1.sources.fs1.interceptors.i1.serializers = s1
a1.sources.fs1.interceptors.i1.serializers.s1.name = extracted
a1.sinks.hdfs-sink.type = file_roll
a1.sinks.hdfs-sink.sink.directory = /tmp/spooldir2
a1.channels.parse.type = memory
a1.channels.parse.capacity = 1000
a1.channels.parse.transactionCapacity = 100
a1.sources.fs1.channels = parse
a1.sinks.hdfs-sink.channel = parse

C extension for Tcl built in LabWindows crashing after upgrading to Tcl 8.6

Okay, so we have an extension that is written in C for Tcl 8.4 using LabWindows. After upgrading to Tcl 8.6 calling any procedures that were produced by the dll causes wish to crash without producing a useful error code. This happens from both a script and if I manually load the library and call a procedure from the wish shell.
Now, this only happens when I install Tcl 8.6 over 8.4. If I do a fresh install of 8.6 it says the the dll is missing a dependent library. So, I used dependency walker to see that the dll is dependent on tcl84.dll whereas my extensions made with Visual Studio(VS) and even other old LabWindows projects also don't have this listed as a dependency.
Any project that doesn't have tcl84.dll listed as a dependency, as you might expect, works fine on Tcl 8.6, both a fresh install and being installed over 8.4.
So does anyone have any idea why the extension is dependent on tcl84.dll when others are not?
Here's the source:
SI.c only up to the init method(entire file is too large)
#include <analysis.h>
#include "toolbox.h"
#include <utility.h>
#include <ansi_c.h>
#include "SI.h"
////////////////////////////////////////////////////////////////////////////////////////////////////
int DLLEXPORT Si_Init(Tcl_Interp *interp) {
////////////////////////////////////////////////////////////////////////////////////////////////////
if (Tcl_InitStubs(interp, "8.4", 0) == NULL) {
return TCL_ERROR;
}
//TCL Exported Functions
Tcl_CreateObjCommand(interp, "LoadWfm", (Tcl_ObjCmdProc*)LoadWfm,(ClientData)NULL, (Tcl_CmdDeleteProc *)NULL);
Tcl_CreateObjCommand(interp, "SaveWfm", (Tcl_ObjCmdProc*)SaveWfm,(ClientData)NULL, (Tcl_CmdDeleteProc *)NULL);
Tcl_CreateObjCommand(interp, "Step2SParam", (Tcl_ObjCmdProc*)Step2SParam,(ClientData)NULL, (Tcl_CmdDeleteProc *)NULL);
Tcl_CreateObjCommand(interp, "Step2Eye", (Tcl_ObjCmdProc*)Step2Eye,(ClientData)NULL, (Tcl_CmdDeleteProc *)NULL);
Tcl_PkgProvide(interp, "SI", "1.0");
return TCL_OK;
}
SI.h
//Exported Functions
int DLLEXPORT Si_Init(Tcl_Interp *interp);
int DLLEXPORT LoadWfm(ClientData clientData, Tcl_Interp *interp,int objc, Tcl_Obj *CONST objv[]);
int DLLEXPORT SaveWfm(ClientData clientData, Tcl_Interp *interp,int objc, Tcl_Obj *CONST objv[]);
int DLLEXPORT Step2SParam(ClientData clientData, Tcl_Interp *interp,int objc, Tcl_Obj *CONST objv[]);
int DLLEXPORT Step2Eye(ClientData clientData, Tcl_Interp *interp,int objc, Tcl_Obj *CONST objv[]);
//Local Functions
int StepToSParam (double *vin, double *vout, double dt, int N, double **S_real_out, double **S_imag_out, double *S_f0_out, double *S_df_out, int *S_N_out);
double RisetimeToBandwidth_20_80(double x);
double RisetimeToBandwidth_10_90(double x);
int GaussianFilter(double *Waveform, int Samples, double SampleTime, int BitPoints, double Bandwidth);
int NormalizeAmplitude (double *Waveform, int Samples, double Vpp);
int FunctionGenerator(int BitPattern[], int PatternLength, int PatternCycles, double Freq, double Vpp, double Risetime,
int Risetime2080, double dt, int *Samples, double **Waveform);
int ZeroPad (double **wfm, int N, int NewN);
int ParZ(double Z1_Re, double Z1_Im, double Z2_Re, double Z2_Im, double *ZT_Re, double *ZT_Im);
int ReflCoef(double Z1_Re, double Z1_Im, double Z2_Re, double Z2_Im, double *ZRefl_Re, double *ZRefl_Im);
int SixCompEq(double f, double Zcab, double Rld, double R1, double C, double R3, double L, double *T_Re, double *T_Im);
int FourCompEq(double f, double Zcab, double Rld, double R1, double C, double R3, double L, double *T_Re, double *T_Im);
int ApplyEq(int NumComponents, int EQ_N, double df, double Zcab, double Rld, double R1,
double C, double R3, double L, double *T_Re, double *T_Im);
int SimulateEye (double *in, double *out, int N, double dt,
char *Pattern_String, int Pattern_Inverted, int Pattern_Cycles, double Pattern_BitRate,
double Pattern_Risetime, int Pattern_2080, double Pattern_Amplitude,
int EQ_NumComponents, double EQ_Zcab, double EQ_Rld, double EQ_R1, double EQ_C, double EQ_R3, double EQ_L,
double **Eye_Pattern, double *Eye_dt, int *Eye_N);
int FindPatternStartIndex(double *EyeWfm, double Eye_dt, int Eye_N, double Pattern_Bitrate, int Pattern_Bits, int Pattern_Cycles);
And if anyone is familiar with LabWindows, here's the project setting files:
SI.prj
[Project Header]
Version = 800
Pathname = "/c/CVS_CHECKOUT/MHTS/SI/SI.prj"
CVI Dir = "/c/program files/national instruments/cvi80"
IVI Standard Root Dir = "/C/Program Files/IVI"
VXIplug&play Framework Dir = "/C/VXIPNP/winnt"
Number of Files = 4
Target Type = "Dynamic Link Library"
Flags = 16
[File 0001]
File Type = "Include"
Res Id = 1
Path Is Rel = True
Path Rel To = "Project"
Path Rel Path = "../Include/molex_tcl.h"
Path = "/c/CVS_CHECKOUT/MHTS/Include/molex_tcl.h"
Exclude = False
Project Flags = 0
Folder = "Included Files"
[File 0002]
File Type = "CSource"
Res Id = 2
Path Is Rel = True
Path Rel To = "Project"
Path Rel Path = "SI.c"
Path = "/c/CVS_CHECKOUT/MHTS/SI/SI.c"
Exclude = False
Compile Into Object File = False
Project Flags = 0
Folder = "Source Files"
[File 0003]
File Type = "Include"
Res Id = 3
Path Is Rel = True
Path Rel To = "Project"
Path Rel Path = "SI.h"
Path = "/c/CVS_CHECKOUT/MHTS/SI/SI.h"
Exclude = False
Project Flags = 0
Folder = "Source Files"
[File 0004]
File Type = "Library"
Res Id = 4
Path Is Rel = True
Path Rel To = "Project"
Path Rel Path = "../Include/tclDecls.lib"
Path = "/c/CVS_CHECKOUT/MHTS/Include/tclDecls.lib"
Exclude = False
Project Flags = 0
Folder = "Included Files"
[Folders]
Include Files Folder Not Added Yet = True
User Interface Files Folder Not Added Yet = True
Instrument Files Folder Not Added Yet = True
Folder 0 = "Source Files"
Folder 1 = "Included Files"
[Compiler Options]
Default Calling Convention = "cdecl"
Require Prototypes = True
Require Return Values = True
Enable Pointer Mismatch Warning = False
Enable Unreachable Code Warning = False
Enable Unreferenced Identifiers Warning = False
Enable Assignment In Conditional Warning = False
O Option Compatible With 5.0 = False
Uninitialized Locals Compile Warning = "Conservative"
[Run Options]
Stack Size = 250000
Image Base Address = 4194304
[Compiler Defines]
Compiler Defines = "/DWIN32_LEAN_AND_MEAN /D_MSC_VER=1200 /D_WINDEF_"
[Include Paths]
Include Path 1 Is Rel = False
Include Path 1 = "/c/CVS_CHECKOUT/MHTS/Include"
Include Path 2 Is Rel = False
Include Path 2 = "/c/Tcl/include"
[Create Executable]
Executable File_Debug Is Rel = True
Executable File_Debug Rel To = "Project"
Executable File_Debug Rel Path = "SI_dbg.dll"
Executable File_Debug = "/c/CVS_CHECKOUT/MHTS/SI/SI_dbg.dll"
Executable File_Release Is Rel = True
Executable File_Release Rel To = "Project"
Executable File_Release Rel Path = "SI.dll"
Executable File_Release = "/c/CVS_CHECKOUT/MHTS/SI/SI.dll"
Icon File Is Rel = False
Icon File = ""
Application Title = ""
DLL Exports = "Symbols Marked As Export"
DLL Import Library Choice = "Gen Lib For Current Mode"
Use IVI Subdirectories for Import Libraries = False
Use VXIPNP Subdirectories for Import Libraries = False
Use Dflt Import Lib Base Name = True
Where to Copy DLL = "Do not copy"
Add Type Lib To DLL = False
Include Type Lib Help Links = False
Type Lib FP File Is Rel = False
Type Lib FP File = ""
Type Lib Guid = ""
Runtime Support = "Full Runtime Support"
Instrument Driver Support Only = False
Embed Project .UIRs = False
Generate Map File = False
[External Compiler Support]
UIR Callbacks File Option = 0
Using LoadExternalModule = False
Create Project Symbols File = True
UIR Callbacks Obj File Is Rel = False
UIR Callbacks Obj File = ""
Project Symbols H File Is Rel = False
Project Symbols H File = ""
Project Symbols Obj File Is Rel = False
Project Symbols Obj File = ""
[ActiveX Server Options]
Specification File Is Rel = False
Specification File = ""
Source File Is Rel = False
Source File = ""
Include File Is Rel = False
Include File = ""
IDL File Is Rel = False
IDL File = ""
Register ActiveX Server = False
[tpcSection]
tpcEnabled = 0
tpcOverrideEnvironment = 0
SI.cws
[Workspace Header]
Version = 800
Pathname = "/c/CVS_CHECKOUT/MHTS/SI/SI.cws"
CVI Dir = "/c/program files/national instruments/cvi80"
IVI Standard Root Dir = "/C/Program Files/IVI"
VXIplug&play Framework Dir = "/C/VXIPNP/winnt"
Number of Projects = 1
Active Project = 1
Project 0001 = "SI.prj"
Drag Bar Left = 323
Window Top = 137
Window Left = 1190
Window Bottom = 1041
Window Right = 2278
Maximized = True
Maximized Children = True
Max Number Of Errors = 20
Track Include File Dependencies = True
Prompt For Missing Includes = True
Stop On First Error File = False
Bring Up Err Win For Warnings = True
Show Build Dialog = False
Save Changes Before Running = "Always"
Hide Windows = False
Global Hot Key = False
Break At First Statement = False
Sort Type = "File Name"
Number of Opened Files = 3
Window Confinement Region Enabled = True
MainColumnWidth = 304
FileDateColumnWidth = 70
FileSizeColumnWidth = 70
StatusColumnWidth = 70
[Project Header 0001]
Version = 800
Don't Update DistKit = False
Platform Code = 4
Build Configuration = "Release"
Warn User If Debugging Release = 1
Batch Build Release = False
Batch Build Debug = False
Force Rebuild = False
[File 0001]
Path = "/c/CVS_CHECKOUT/MHTS/SI/SI.c"
File Type = "CSource"
Disk Date = 3288546022
In Projects = "1,"
Window Top = 163
Window Left = 78
Window Z-Order = 1
Source Window State = "1,191,191,191,54,55,55,0,0,116,0,25,0,25,0,51,150,0,192,6,349,676,1,0,"
Breakpoint 0001 = "166,0,enabled,"
Breakpoint 0002 = "195,0,enabled,"
[File 0002]
Path = "/c/CVS_CHECKOUT/MHTS/SI/SI.h"
File Type = "Include"
Disk Date = 3262700601
In Projects = "1,"
Window Top = 30
Window Left = 6
Window Z-Order = 2
Source Window State = "1,27,28,27,0,0,0,0,0,80,0,28,0,28,0,25,0,45,27,130,349,676,1,0,"
[File 0003]
Path = "/c/CVS_CHECKOUT/MHTS/Include/molex_tcl.h"
File Type = "Include"
Disk Date = 3275700706
In Projects = "1,"
Window Top = 30
Window Left = 6
Window Z-Order = 3
Source Window State = "1,15,16,16,86,159,159,0,0,80,0,0,0,0,0,25,0,0,35,33,349,676,1,0,"
[File 0004]
Path = "/c/CVS_CHECKOUT/MHTS/Include/tclDecls.lib"
File Type = "Library"
Disk Date = 3262622625
In Projects = "1,"
[Build Options 0001]
Generate Browse Info = True
Enable Uninitialized Locals Runtime Warning = True
Debugging Level = "Standard"
Break On Library Errors = False
Break On First Chance Exceptions = False
Execution Target Address = "Local desktop computer"
Execution Target Port = 0
Execution Target Type = 0
[SCC Options 0001]
Use global settings = True
SCC Provider = ""
SCC Project = ""
Local Path = ""
Auxiliary Path = ""
Perform Same Action For .h File As For .uir File = "Ask"
Username = ""
Comment = ""
Use Default Username = False
Use Default Comment = False
Suppress CVI Error Messages = False
[DLL Debugging Support 0001]
External Process Path = "/c/Tcl/bin/wish.exe"
[DLLs Used By Executable 0001]
DLL 0001 = "/C/Tcl/bin/tcl84.dll"
[Command Line Args 0001]
Command Line Args = ""
The most promising possibility looks to be this line in the .cws file:
[DLLs Used By Executable 0001]
DLL 0001 = "/c/Tcl/bin/tcl84.dll"
but here is the .cws file from another LabWindows project:
OK.cws
[Workspace Header]
Version = 800
Pathname = "/c/CVS_CHECKOUT/MHTS/OK/OK.cws"
CVI Dir = "/c/program files/national instruments/cvi80"
IVI Standard Root Dir = "/C/Program Files/IVI"
VXIplug&play Framework Dir = "/C/VXIPNP/winnt"
Number of Projects = 1
Active Project = 1
Project 0001 = "OK.prj"
Drag Bar Left = 181
Window Top = 101
Window Left = 1404
Window Bottom = 974
Window Right = 2676
Maximized = True
Maximized Children = True
Max Number Of Errors = 20
Track Include File Dependencies = True
Prompt For Missing Includes = True
Stop On First Error File = False
Bring Up Err Win For Warnings = True
Show Build Dialog = False
Save Changes Before Running = "Always"
Hide Windows = False
Global Hot Key = False
Break At First Statement = False
Sort Type = "File Name"
Number of Opened Files = 1
Window Confinement Region Enabled = True
MainColumnWidth = 162
FileDateColumnWidth = 70
FileSizeColumnWidth = 70
StatusColumnWidth = 70
[Project Header 0001]
Version = 800
Don't Update DistKit = False
Platform Code = 4
Build Configuration = "Debug"
Warn User If Debugging Release = 1
Batch Build Release = False
Batch Build Debug = False
Force Rebuild = False
[File 0001]
Path = "/c/CVS_CHECKOUT/MHTS/OK/OK.c"
File Type = "CSource"
Disk Date = 3291811857
In Projects = "1,"
Window Top = 59
Window Left = 80
Window Z-Order = 1
Source Window State = "1,503,503,503,14,32,32,0,0,133,0,37,0,51,29,59,478,0,514,78,663,815,1,0,"
[File 0002]
Path = "/c/CVS_CHECKOUT/MHTS/Include/molex_tcl.h"
File Type = "Include"
Disk Date = 3275700706
In Projects = "1,"
Window Top = 48
Window Left = 18
Source Window State = "1,8,9,8,0,0,0,0,0,0,0,0,0,0,0,0,1,0,8,12,461,988,1,0,"
[File 0003]
Path = "/c/CVS_CHECKOUT/MHTS/OK/OK.h"
File Type = "Include"
Disk Date = 3291811853
In Projects = "1,"
Window Top = 614
Window Left = 299
Source Window State = "1,4,4,4,17,21,17,0,0,0,0,16,0,16,0,0,0,0,15,17,278,676,1,0,"
[File 0004]
Path = "/c/Program Files/Opal Kelly/FrontPanel/API/okFrontPanelDLL.h"
File Type = "Include"
Disk Date = 3268500132
In Projects = "1,"
Window Top = 130
Window Left = 11
Source Window State = "1,218,218,218,51,68,51,0,3,0,0,0,0,0,0,0,197,0,218,68,476,725,1,0,"
[File 0005]
Path = "/c/CVS_CHECKOUT/MHTS/Include/tclDecls.lib"
File Type = "Library"
Disk Date = 3262622625
In Projects = "1,"
[Build Options 0001]
Generate Browse Info = True
Enable Uninitialized Locals Runtime Warning = True
Debugging Level = "Standard"
Break On Library Errors = False
Break On First Chance Exceptions = False
Execution Target Address = "Local desktop computer"
Execution Target Port = 0
Execution Target Type = 0
[SCC Options 0001]
Use global settings = True
SCC Provider = ""
SCC Project = ""
Local Path = ""
Auxiliary Path = ""
Perform Same Action For .h File As For .uir File = "Ask"
Username = ""
Comment = ""
Use Default Username = False
Use Default Comment = False
Suppress CVI Error Messages = False
[DLL Debugging Support 0001]
External Process Path = "/c/Tcl/bin/wish.exe"
[DLLs Used By Executable 0001]
DLL 0001 = "/c/Tcl/bin/tcl84.dll"
[Command Line Args 0001]
Command Line Args = ""
...it has the same line, yet this project works properly after updating to Tcl 8.6.
UPDATE 5/13/2013 9:00 AM - From what I can tell from all the answers and comments so far is that it definitely has to have something to do with some idiosyncratic in the LabWindows build. So, I'll be getting a copy of it hopefully by the end of the work day today and I'll update my question with the results.
UPDATE 5/13/2013 2:13 PM - Okay so I got LabWindows and first tried deleting the line in the .cws file and re-compiling. The IDE simply re-generates the line before compiling and ends up with the same result. So, I then created a new project from scratch and brought over only the .c and .h files. I set up all the includes and project settings manually and when I got a successful build I looked at the .cws file and the line had been auto-generated again producing the same results. Therefore, there must some function call or reference in the .c or .h file that is referencing tcl84.dll. Any additional insights would be very much appreciated.
You properly use the Tcl STUBS support with your call to Tcl_InitStubs() but throw the benefits out of the window by linking with Tcl84.dll.
If you use Stubs, you only need to link with the stubs version of the oldest DLL you need. In this case the lib called 'tclstub84.lib'. This static library takes care of the magic needed to allow a Tcl 8.6 to load a 8.4 library without recompiling.
You probably need the TCL_USE_STUBS compiler define too, to make it work properly.
See http://tcl.activestate.com/doc/howto/stubs.html for further details how to properly enable STUBS support for your library.
Deep within SI.cws you have
[DLLs Used By Executable 0001]
DLL 0001 = "/C/Tcl/bin/tcl84.dll"
which looks as though it's where the dependency comes from.
That's the easy bit. I'm unfamiliar LabWindows and VisualStudio, so I have no informed idea what you should do to resolve this.
Mind you, changing the above line to specify tcl86.dll looks tempting :-)