I am developing on a Qt project, and have installed Qt from their installer onto my computer. In Visual Studio it is simple to debug-step into Qt sources: when I enter a function in an unknown file, it will open a file browser to let me locate the original Qt source code.
Is there an equivalent function in Xcode or LLDB?
The debug information records the location of the QT source files when they were built. You can find this information by doing:
(lldb) image lookup -va main
Address: hello[0x0000000100000f40] (hello.__TEXT.__text + 0)
Summary: hello`main at hello.c:5
Module: file = "/private/tmp/hello", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "/tmp/hello.c", language = "ISO C:1999"
Function: id = {0x00000026}, name = "main", range = [0x0000000100000f40-0x0000000100000f6d)
FuncType: id = {0x00000026}, decl = hello.c:4, clang_type = "int (void)"
Blocks: id = {0x00000026}, range = [0x100000f40-0x100000f6d)
LineEntry: [0x0000000100000f40-0x0000000100000f56): /tmp/hello.c:5
Symbol: id = {0x00000004}, range = [0x0000000100000f40-0x0000000100000f6d), name="main"
but substitute some QT function for "main". Then look at the CompileUnit line and see what the "file" entry says. Suppose it says
"/BuildDirectory/sources/SomeSubdirectory/SomeFile.cpp"
Now presumably you've downloaded the QT sources, and they live somewhere on your local machine, say in
"/Users/ME/QT/sources"
So what you want to do is tell lldb: "when you see a source file rooted at /BuildDirectory/sources, look in /Users/ME/QT/sources instead." You do that with the lldb "target.source-map" setting. In this example, you would say:
(lldb) settings set target.source-map /BuildDirectory/sources /Users/ME/QT/sources
You can type that in on the command line or put it in your .lldbinit file for more general use. lldb will update its source maps automatically, but if you are running in Xcode, you'll have to step once after issuing the command to get it to update.
Related
I've tried to get an audio library statically linked to my program. I use this nimble package. To get it run, i had to build the soloud library as described here. For short after download i ran "genie --with-miniaudio-only --platform=x64 vs2017" in the "build" folder and got the source code to generate the dynamic and the static library. For now i can run the following demo program from the nimble package with the generated dll alongside:
import solouddotnim, times, os
var i, spin = 0
var sl : ptr Soloud
sl = Soloud_create()
discard Soloud_init(sl)
Soloud_setGlobalVolume(sl, 1)
var stream = WavStream_create()
discard WavStream_load(cast[ptr Wav](stream), "test.ogg")
let currentTime = epochTime()
let length = WavStream_getLength(stream)
discard Soloud_play(cast[ptr Soloud](sl), cast[ptr Wav](stream))
while epochTime() - currentTime <= length:
sleep(100)
Soloud_deinit(sl)
Soloud_destroy(sl)
Now to the static-link part. In the solouddotnim.nim file of the nimble package i use, i see this part:
when defined(windows):
const
libname* = "libsoloud.dll"
elif ...
So i simple changed the windows part to the following, re-installed the nimble-package and placed the "soloud_static_x64.lib" alongside to the "main.nim" of the testproject:
when defined(windows):
const
libname* = "soloud_static_x64.lib"
elif ...
But this doesent make it. (cant open "soloud_static_x64.lib" error when build)
Evereywhere where the constant "libname" is used there are the pragmas "cdecl", "importc" and "dynlib". For example:
proc Soloud_create*(): ptr Soloud {.cdecl, importc: "Soloud_create", dynlib: libname.}
So "dynlib" is telling nim to use a dll on windows. But was is the pragma for static libraries?
In the nim documentations i only found DynlibOverride to link to static libraries, but i dont understand the example and here is where i stuck. I've tried the followings:
nim c --dynlibOverride:libname --passL:soloud_static_x64.lib "examples\00-ogg\Example00_ogg.nim"
nim c --dynlibOverride:soloudtotnim --passL:soloud_static_x64.lib "examples\00-ogg\Example00_ogg.nim"
Firstly i dont know what parameter dynlibOverride expects and secondly both compiles, but dont work. It expects a dynamic library alongside the exe.
My last try was to remove all dynlib pragmas from the nimble package. But now i cant compile it.
undefined reference to `Soloud_create'
...
Error: execution of an external program failed: 'gcc.exe...
My knowlege ends here. Can someone help me?
Thanks in advance.
Edit:
I could not get any of your solutions work. I break down the problem as small as possible so everybody can reproduce this:
"foo.nim" contains this:
proc add*(a, b: int): int {.cdecl, exportc.} =
a + b
proc sub*(a, b: int): int {.cdecl, exportc.} =
a - b
The .lib is simply generated with this command: "nim c --app:staticlib foo.nim"
Now to use it i created a file "main.nim" with this content:
{.passL:"foo.lib".}
proc add*(a, b: int):int {.cdecl, importc.}
proc sub*(a, b: int):int {.cdecl, importc.}
echo add(10, 5)
echo sub(10, 5)
if i simply build it with "nim c -r main.nim", i get the following output and error:
P:\Nim\LearnCBinding>nim c -r main.nim
Hint: used config file 'C:\nim-1.5.1\config\nim.cfg' [Conf]
Hint: used config file 'C:\nim-1.5.1\config\config.nims' [Conf]
....CC: stdlib_io.nim
CC: stdlib_system.nim
CC: main.nim
Hint: [Link]
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x1f6): multiple definition of `PreMainInner'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x120): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x20a): multiple definition of `PreMain'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x134): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x240): multiple definition of `NimMainInner'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x16f): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x254): multiple definition of `NimMain'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x183): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x285): multiple definition of `main'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x1b4): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x2da): multiple definition of `NimMainModule'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x209): first defined here
collect2.exe: error: ld returned 1 exit status
Error: execution of an external program failed: 'C:\nim-1.5.1\dist\mingw64\bin\gcc.exe -o P:\Nim\LearnCBinding\main.exe C:\Users\Peter\nimcache\main_d\stdlib_io.nim.c.o C:\Users\Peter\nimcache\main_d\stdlib_system.nim.c.o C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o foo.lib '
Because of the multiple definition error i also tried to build foo.lib with parameter "--noMain:on", but it doesnt make any difference.
Do you have the same problem? By the way i use the current version of Nim "nim-1.5.1" and reinstalled MingW with the finish.exe from nim.
I will try to help you with the following error you have:
undefined reference to `Soloud_create'
but i will assume that you have configured your environment so you can compile your nim programs with visual studio compiler (by adding --cc:vcc to your compile command)
this is because you already seem to have visual studio 2017 and you are compiling soloud static library with it. I think this is the best option when you are compiling with one compiler both: static library and executable that will use it.
open your static library (soloud_static_x64.lib) with some text/hex editor and search for "Soloud_create". i guess you will not find anything. so why is that? because for some reason author decided to not include "C interfacing" in a static library project. so it contains only C++ symbols and not pure C symbols that are needed for our solouddotnim.nim module.
let's try to find out what .cpp file we need for that. i noticed this information on official web site of Soloud - http://sol.gfxile.net/soloud/c_api.html
so i guess we need only one file: soloud_c.cpp
let's try to just include it in SoloudStatic.vcxproj file generated by you with Genie. like this:
..
<ClCompile Include="..\..\src\c_api\soloud_c.cpp">
</ClCompile>
..
and recompile our static library. i use this command in powershell:
& 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\MSBuild.exe' /p:PlatformToolset=v142`;WindowsTargetPlatformVersion=10`;Configuration=Release`;Platform=x64 .\SoloudStatic.vcxproj
but you can compile how you want. just make sure that it's architecture is really x64. you can check it with this command:
dumpbin /headers soloud_static_x64.lib | more
finally just link it with your nim file. add this line to the top:
{.link:"soloud_static_x64.lib".}
and compile nim file with this command:
nim c --cc:vcc --dynlibOverride:libsoloud.dll -r "examples\00-ogg\Example00_ogg.nim"
I'm trying to use CreateTextServices function in TextServ.h. It seem I have to link riched20.lib to project to use this function.
But when I add riched20.lib to Linker/Input/Additional Depedencies, VS say error LNK1181: cannot open input file 'riched20.lib'.
How to fix this error?
I'm using VS 2013, Win 8.1 32 bit.
Had the same issue. I think there's no lib available for recent versions of richedit/msftedit, but textserv.h provides a definition of the function, so what you can do without any need for an extra .lib is this:
// load the dll and get the function address
// PCreateTextServices is declared in textserv.h:
HMODULE h = LoadLibrary(L"msftedit.dll");
PCreateTextServices createTextServices = (PCreateTextServices)GetProcAddress(h, "CreateTextServices");
...
ITextServices svc*;
int hr = createTextServices(NULL, host, (IUnknown**)&svc);
...
svc->Release();
FreeLibrary(h);
Hi I am trying to work with the rcpp. For this I want some cpp code which loads a dll by use of a lib-file (which has the same name as ). the code which I let run is:
cppFunction(includes=c("#include "windef.h","#include \"C:/data/Rdata/IHUAPI.H\" "), 'int functietom(int a){long serverhandle;int lRet;lRet = ihuConnect ( "historian1",NULL,NULL, &serverhandle ); return 5;}', verbose
= TRUE)
I get the following error:
undefined reference to `ihuConnect#16' collect2: ld returned 1 exit
status Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object
'C:/Users/user1663/AppData/Local/Temp/RtmpSW1Ki7/sourcecpp_1a04df63309/sourceCpp_26588.dll':
LoadLibrary failure:
the ihuConnect function is located in the ihuapi.lib and ihuape.dll files. In c++ in visual studio I add the lib file as added dependency and then I get rid of this error because I also sometimes get this error and then it was that I forgot to add the lib file in the compilation.
Thus My question is: how can I add this lib file as option in the compilation.
when I use dyn.load
("C:/data/Rdata/ihUAPI.dll")
and then check if it is loaded then he says yes
the problem is that getDLLRegisteredRoutines('ihUAPI', addNames = TRUE)
then it says:
data frame with 0 columns and 0 rows
so the dll seems not to contain the functions but it does when I use it from visual studio.
So please some help with lib-files and ddl-files
Tom Wambecq
You missed the Rcpp FAQ entry 2.9 'Can I use Rcpp with Visual Studio ?'.
And to kill all the suspense: No, you cannot.
I have a minidump from a customer. I want to find out the assembly versions of the loaded .NET dlls. I've already searched the internet for hours now, but cannot find a usable way.
I have windbg and have loaded SOS extension an have the needed clr.dll and mscordacwks.
using lm -v only shows the unmanaged dll's. I am sure I am overlooking something very simple.
WinDbg's lm v shows all DLLs, managed and unmanaged. On that level, an assembly is just a DLL, is just a module.
With WinDbg 6.3.9600, lm v even shows information whether a modules has a CLR header or not:
0:008> lmv m MyApp
start end module name
10310000 10574000 MyApp(deferred)
Image path: C:\...\MyApp.exe
Image name: MyApp.exe
Has CLR image header, track-debug-data flag not set
Timestamp: Wed May 21 16:34:02 2014 (537CB95A)
...
ProductVersion: 1.8.0.44
FileVersion: 1.8.0.44
...
However, the FileVersion and ProductVersion is still unmanaged information compiled into the native resource part of the DLL.
I suggest you use !SaveModule <start address> <filename> to save the file on disk and then use a reflection tool like dotPeek to open it and get the assembly information from there, which will give you the name, version, culture and public key token.
To save all modules, Naveen has written a script like this:
!for_each_module .if ($spat ("${##ImageName}","*.exe")) { !SaveModule ${##Base} c:\temp\${##ModuleName}.exe } .else { !SaveModule ${##Base} c:\temp\${##ModuleName}.dll }
Alright, after some more research I came to the conclusion that that kind of information is just not available for those dll's in a minidump. Anyway I was at least able to get some more information about the files, and maybe this is useful for someone else in the future.
You can get at least the metata information of the dll's, and maybe you can find something useful in there. Here's how to do that:
First get the domain:
!dumpdomain
You might end up with a large amount of listed assemblies. Now you can either look them up by hand using:
!dumpassembly ADDRESS
or you can just use the lazy way: Install the python extension for windbg (http://pykd.codeplex.com/) and use the following script for a quick overlook (it's maybe not the nicest script, but it's working and I didn't want to invest more time):
import pykd
def dump_assemblies():
assemblies = 0
addrs = pykd.dbgCommand("!dumpdomain").splitlines()
for x in addrs:
if x[:8] == "Assembly":
assemblies = assemblies + 1
print "### retrieving assembly " + x[-8:]
print pykd.dbgCommand("!dumpassembly " + x[-8:])
print "### found " + str(assemblies) + " assemblies."
dump_assemblies()
You will now be able to do a text search (CTRL + F) for the dll. Once you found it, you can find the offset next to the module name (looks something like 12327C8 C:\Program Files\MyApp\MyDLL.dll).
You can now dump the module using:
!dumpmodule 12327C8
which will lead you to:
Name: C:\Program Files\MyApp\MyDLL.dll
Attributes: PEFile
Assembly: 131a22e2
LoaderHeap: 00000000
TypeDefToMethodTableMap: 19220010
TypeRefToMethodTableMap: 134303e0
MethodDefToDescMap: 13430740
FieldDefToDescMap: 13433964
MemberRefToDescMap: 134350c8
FileReferencesMap: 13435918
AssemblyReferencesMap: 1343591c
MetaData start address: 1c1aaa4c (4248 bytes)
Now you can check the metadata of the dll simply with:
dc 1c1aaa4c 1c1aaa4c + 4248
That's the closest I could get to more information about the DLL. Unfortunately the file version was not written there, just some other more generic info. Anyway, I will try to get in touch with the customer again. Thanks for the answers anyway.
I’m using Xcode 4.6.3 to build a library for OS X. My project includes a target called LibraryTest, which is a command-line app to test the functionality of the library. Both the library and the test app build fine, but when I try to run the app it quits immediately and the debug console shows:
error: failed to launch '/Users/bdesham/Library/Developer/Xcode/DerivedData/Wavelength_and_Spectrum_Library-byosniusyaoidgdcpzwzuzkitzgv/Build/Products/Debug/LibraryTest'
-- error: Host::LaunchProcess (launch_info) => pid=0,
path='/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver'
err = error: ::posix_spawnp (
pid => 98649,
path = '/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver',
file_actions = 0x10b09e268,
attr = 0x10b09e2a0,
argv = 0x7fe2701377e0,
envp = 0x0 )
err = Bad file descriptor (0x00000009) (0x00000009)
error: failed to launch '/Users/bdesham/Library/Developer/Xcode/DerivedData/Wavelength_and_Spectrum_Library-byosniusyaoidgdcpzwzuzkitzgv/Build/Products/Debug/LibraryTest'
-- error: Host::LaunchProcess (launch_info) => pid=0,
path='/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver'
err = error: ::posix_spawnp (
pid => 98649,
path = '/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver',
file_actions = 0x10b09e268,
attr = 0x10b09e2a0,
argv = 0x7fe2701377e0,
envp = 0x0 )
err = Bad file descriptor (0x00000009) (0x00000009)
(Line breaks added for readability.) I have the Xcode 5 DP installed, so I tried removing Xcode 4 and reinstalling it from the Mac App Store, but no dice. Deleting DerivedData didn’t help either. Any ideas?
Restarting my Mac seems to have fixed this.
Check "Build Settings" -> "Provisioning Profile". It should be "none" or some provisioning for Max OSX (if you're building for the app-store) . In my case it erroneously had "iOS Ad Hoc Provisioning Profile". This resolved this problem for me.
Note: I found this out by checking the syslog ("cat -f /var/log/system.log" in terminal, then start app). It wrote a crash report which had "...embedded provisioning profile not valid:..." among other lines. Checking the app container itself indeed showed an "embedded.provisionprofile" file, which triggered me to check the build settings for it.
I solved it by updating iOS. I was using JailBreak iOS version.