I am developing for iOS with XCode 3.2. I compiled my code in debug mode with the -g option into a static library. I then linked this library with a bigger static library which has the main to create the final executable. This library was built in release mode without any of the debugging support. Now when debugging crashes, I don't see the symbols for my code. Where did they go? Were they stripped by the linker? How can I make the linker retain the debugging information for my library? I have no control over the other library so I won't be able to do anything there.
If you can build your library, in the Build Settings
Use the same Debug Information Format for both the library and your code. mixing for example "DWARF with dSYM File " with "DWARF" will not display the symbols
Build it with any flag related "strip" to NO (or deployment Postprocessing NO)
Related
I am building an .xcframework which contains an iphonesimulator and iphoneos frameworks. There is some Swift code, and some C++ code, which is linked into a shared object (Mach-O 64-bit dynamically linked shared library arm64). I build my C++ with -fvisibility=hidden, and only the symbols that I explicitly mark, are exported. But, when I run nm -gC, I see all kinds of symbols that are still there – and they are visible even in the iOS app that is built using this framework. For example, I have an inner class Secret (it is only used in one cpp file). And nm -gC shows me (and all hackers out there)
00010292 t Secret::getString() const
Is there a way to hide this and other sensitive information?
And, on the other hand, how can I keep the auto-generated _AlexSDKVersionNumber exported?
You should configure your project settings correctly for Stripping to hide internal names.
Go to Your target > Build Settings > Deployment:
Set Deployment Postprocessing to YES to enable Stripping.
Set Strip Style to Non-Global Symbols.
Now nm should provide global (external) symbols only for your binary.
As for keeping the auto-generated _AlexSDKVersionNumber exported, I came up with a not-so-dirty hack:
add a header file to my project, call it AlexSDK_vers.h:
extern __attribute__ ((visibility("default"))) const double AlexSDKVersionNumber;
in Build Settings, add OTHER_CFLAGS=-include\${PWD}/AlexSDK/AlexSDK_vers.h
I am building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.
Using Xcode, I've written a Cocoa Touch static library, mainly in C++. It exposes a C interface for the benefit of Objective-C client code.
I have a client iOS app that uses it, and everything works and runs as expected, except that I found I needed to include a minimal .cpp file in the client project to get the link to succeed. Otherwise I get C++-related unresolved symbols, e.g. operator new(unsigned long).
The above hack is easy and effective, and so I guess I'm not breaking any laws, but is there a proper way to eliminate my linker errors?
Should be just a matter of adding -lc++ to the linker flags in the project settings, I'd have thought.
Add it under "Other Linker Flags" under "Linking" section of the "Build Settings" tab on your project's settings.
Is it possible to symbolicate MonoTouch crash dumps and get line numbers out of them? If so, how is it done?
I have configured my project in the following way:
Build in release mode
Checked 'Enable debugging' in Project Options -> Build -> iPhone Build -> General tab
Checked 'Emit debugging information' in Project Options -> Build -> Compiler
Now, when I run symbolicatecrash against a dump, I get my method names in the stack trace but with only an offset against them (eg '+ 268') rather than a line number.
I am using MonoTouch 4.21.
Short answer: I think the issue is with the ahead-of-time (AOT) compiler - but you better email such question to the mono-devel mailing-list to get a definitive answer.
Long answer:
Mono compilers/runtime (and that behavior is inherited by MonoTouch) keeps the debugging information, that includes line numbers, for its assemblies inside mdb files.
XCode works with DWARF (DSYM) files. When XCode symbolicate a crash dump it looks (only) in the (AOT-produced) DWARF symbols to get its information - i.e. the mdb files are not looked up.
Now the Mono debugger (and runtime) can cope with DWARF too (which should fit the bill). However for MonoTouch I'm not sure the AOT compiler (which calls gcc) is producing the final DWARF symbols containing the C# line numbers - resulting in symbols and offsets (both available to gcc) only being available.
which version of xcode are you using?
There was an problem in earlier versions -
check https://github.com/chrispix/symbolicatecrash-fix
I have a Xcode project for library arith.
I could build it with debug configuration, and I need to debug it. How can I do that?
The ideal method would be to set up a test code to build an execution in a project file, and then set a breakpoint in a source code in arith library.
However, it seems that Xcode arith project doesn't allow to add another use_arith project that uses the arith library.
What method people use to debug a dynamic library in Xcode?
ADDED
I googled and found some ways to debug dll. Attaching to a running process can be one way of debugging dynamic library. And, for iPhone/iPad programming dynamic library is not allowed, so static library is used.
Attaching to a Running Process - http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Attaching-to-a-Running-Process.html
Debugging a library with Xcode - Debugging a library with Xcode
Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References - http://www.clintharris.net/2009/iphone-app-shared-libraries/
I could find a way to debug dynamic library in Xcode.
Build
Make a library, I'll call this arith library. Debug build to make libarith.dylib.
Make a project to use the library, I'll call this usearith.
For userarith, Project->Add To Project, and add the arith library.
Open Project info, and open the Build tab.
Go to Search Paths/Library Search Paths, drag and drop the arith library. You should remove the library name as you need only specify the path. Specify the header directory with 'Header Search Paths'.
Go to Linking, set Other Linker Flags, add -larith
Running
Now, you should be able to link the execution binary to the library.
For running, you need to copy the dynamic library to the directory where the execution binary is located.
Debugging
You need to set the breakpoints both arith/usearith.
You can run debugger in arith and use the step into to debug the code in a arith project.
I faced the same problem and no one of the previous answer worked for my case so I share my solution (for Xcode):
If you need to debug a c/c++ dylib which is loaded by an external (executable) program:
First be sure that your dylib is build with the same architecture as your external program.
Then Go to --> Product —>Scheme—>Edit scheme
Got to Tab Run(Debug) and check "Debug Executable" , then select into the dropdown button your external program as executable. Then check "Launch Automatically"
Additionally if you program needs extra argument you can add it into the
"Arguments" tab.
Finally you set some breakpoints to your c source file and finally click run.