I've compiled a small program that uses asl_log, and when running in lldb, it failed to print the contents of a global variable from type 'aslclient', although i compiled in debug mode ('-g' flag).
perhaps you can tell me if this is related to the following bug, and how to workaround this problem
[lldb-dev] [Bug 16191] New: LLDB fails to evaluate expressions that
dereference a struct when inferior is built with recent Clang
the input from debugger :
(lldb) print log_asl_client
(aslclient) $5 = 0x0000000100200000
(lldb) print *log_asl_client
(lldb) print *log_asl_client
error: incomplete type '__asl_object_s' where a complete type is required
note: forward declaration of '__asl_object_s'
error: 1 errors parsing expression
my compilation command :
clang -g -c -Wall -DDEBUG=1 example.c -o example.o
clang example.o -o example
the code :
aslclient log_asl_client;
...
int main(int argc, char * const *argv) {
...
log_asl_client = asl_open(identity, facility, client_opts);
...
--> at this point i initiate the print command in debug mode.
the version i use :
clang --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix
thanks,
The debug information has a record for the forward reference to __asl_object_s, but not for the full type. This isn't entirely surprising in this particular case, since the only appearance of __asl_object_s in the public header files on OS X is:
typedef struct __asl_object_s *asl_object_t;
so this is an opaque reference to the struct, and there isn't a real definition anywhere. Presumably __asl_object_s is a placeholder and the pointer gets cast to whatever it really is when it is used.
Anyway, the debugger isn't refusing to show you something, there's actually nothing there to see...
Related
Running the following code with clang++ -S -emit-llvm main.cpp && lli main.ll on Linux(Debian)
#include <future>
int main () {
return std::async([]{return 1;}).get();
}
fails to run on lli due to the following error:
LLVM ERROR: Cannot select: 0xd012e0:
i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8** #_ZSt15__once_callable> 0 [TF=10]
0xd020c0: i64 = TargetGlobalTLSAddress<i8** #_ZSt15__once_callable> 0 [TF=10]
In function: _ZSt9call_onceIMNSt13__future_base13_State_baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_DeleterEEvEEPbEJPS1_S9_SA_EEvRSt9once_flagOT_DpOT0_
Questions:
What does it mean?
Are there any compiler-flags that fix this problem?
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
EDIT:
The motivation behind this question is to understand the differences between libc++ and libstdc++ that leads to this specific error message (on Linux) in llvm's orcjit.
On OSX gcc has been deprecated and clang uses by default libc++.
To reproduce this error on OSX you probably have to install gcc & use -stdlib=libstdc++.
Here is the llvm-ir (it's unfortunately to big to embed it here directly)
EDIT:
The error turned out to be caused by the lack of TLS support in the JITer. This answer describes another problem concerned with linking and lli.
If you have a look at the generated IR from clang++ -std=c++11 -S -emit-llvm test.cpp, you will find that many of the symbols, e.g. _ZNSt6futureIiE3getEv, are only declared, but never defined. The linker is never called, since -S "Only run[s] preprocess and compilation steps" (clang --help).
lli only executes the IR Module and does no "implicit" linking, how is it supposed to know which libraries to link in?
There are different solutions to this, depending on why you are using lli:
compile and link the IR Module: llc main.cpp && clang++ -lpthread main.s (pthread is required s. What is the correct link options to use std::thread in GCC under linux?)
(unconfirmed) use LD_PRELOAD="x.so y.so" to force-load the libraries before running lli
JIT the module programmatically and use LoadLibraryPermanently(nullptr) (adds symbols of the program into the search space) and LoadLibraryPermanently(file, err) for additional libs (s. http://llvm.org/docs/doxygen/html/classllvm_1_1sys_1_1DynamicLibrary.html)
I can only guess as to why libc++ works for you since it fails on my machine, but presumably it's the case because it is loaded into lli already and lli calls sys::DynamicLibrary::LoadLibraryPermanently(nullptr) to add the program's symbols to its JIT search space (s. https://github.com/llvm-mirror/llvm/blob/release_40/tools/lli/OrcLazyJIT.cpp#L110).
The LLVM-dev mailinglist pointed out:
What does it mean?
The llvm-backend in orcjit does currently not support thread-local storage(TLS)
a minimal example is:
extern thread_local int tls;
int main() {
tls = 42;
return 0;
}
using -stdlib=libc++ compiles and runs successfully*; what specific features is libstdc++ using that cause this issue ?
this works because libc++ future::get implementation does not use thread_local keyword.
Are there any compiler-flags that fix this problem?
currently there is no solution.
Using lli -relocation-model=pic trades this problem with a relocation failure.
I'm using Xcode 6.2 to build a C++ command line application.
The Xcode Build Setting Reference states:
If you develop products using C++, you may need to customize these build settings in your targets:
GCC_WARN_EFFECTIVE_CPLUSPLUS_VIOLATIONS (Effective C++ Violation)
However this option does not appear in the build setting list for any of my targets.
Can anyone tell me where it is?
The setting in question no longer has any effect - if you place it into the pbxproj file, it appears as a user defined setting in the UI.
The setting only applies to the gnu g++ compiler, and xcode doesn't ship with that compiler any more (it ships with clang++ and a g++ wrapper that invokes clang++). a brief test of some conditions that trigger with g++ doesn't trigger with clang++ e.g.:
#include <string>
using std::string;
class foo {
string x;
int y;
void *ptr;
public:
foo() : y(1), ptr(0) {}
};
$ g++-4.9 -c -Weffc++ evil.cpp
evil.cpp:5:7: warning: 'class foo' has pointer data members [-Weffc++]
class foo {
^
evil.cpp:5:7: warning: but does not override 'foo(const foo&)' [-Weffc++]
evil.cpp:5:7: warning: or 'operator=(const foo&)' [-Weffc++]
evil.cpp: In constructor 'foo::foo()':
evil.cpp:11:5: warning: 'foo::x' should be initialized in the member initialization list [-Weffc++]
foo() : y(1), ptr(0) {}
^
$ clang++ -c -Weffc++ evil.cpp
$
There are opinions that it is too noisy to be useful - e.g. the complaint about not initializing x (a std::string) is a pointless warning in this situation, and as such is more trouble than it's worth.
You can manually add the -Weffc++ option to the compilation flags for C++ code, you can add it to the option Other C++ Flags, which is under Apple LLVM X.Y - Custom Compiler Flags (the X.Y depends on your version of XCode), but again the LLVM based compiler doesn't process that option.
It looks like the documentation is out of date for this option - I've logged a radar to have the option removed from the docs to prevent this confusion.
I'm trying to use C++11 (with Clang and libc++ on OS X) for a program, but whenever I debug with gdb and try to inspect standard containers, gdb segfaults. Here's a minimal example:
file.cpp:
#include <iostream>
#include <string>
int main(int argc, char* argv[])
{
std::string str = "Hello world";
std::cout << str << std::endl; // Breakpoint here
}
If I compile for C++11 using the following:
$ c++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
$
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 -c file.cpp
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 file.o -o program
And then debug as follows, it crashes when I try to p str.size():
$ gdb program
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done
(gdb) br file.cpp:8
Breakpoint 1 at 0x100000d80: file file.cpp, line 8.
(gdb) run
Starting program: /Users/mjbshaw/School/cs6640/2/program
Reading symbols for shared libraries ++............................. done
Breakpoint 1, main (argc=1, argv=0x7fff5fbffab0) at file.cpp:8
8 std::cout << str << std::endl; // Breakpoint here
(gdb) p str.size()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
std::__1::operator<< <char, std::__1::char_traits<char>, std::__1::allocator<char> > (__os=#0x7fff5fc3d628, __str=#0x1) at string:1243
1243
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long() const) will be abandoned.
If I don't run this in gdb, I get no crash and it works fine (but I need gdb to debug my program). Also, if I remove -std=c++11 -stdlib=libc++ from the compiling options, then it works fine (even in gdb), but I need C++11 for my program.
Are there some known issues with gdb and C++11 (specifically libc++)? I know libc++ and libstdc++ can cause issues if used together, but I'm not trying to use them together (at least not consciously; all I want to use is libc++). Am I specifying some compilation options wrong? Is there a way to properly compile for C++11 on OS X and still be able to debug properly?
GDB 6.3 is almost nine years old. That's just about eternity in Internet years. The product has improved greatly since then. Updating to the last stable release is a must for every developer.
When I run following code snippet from Xcode4.6 it compiles and runs fine. But when I try to compile it using command line tool (clang++) it fails to do so.
#include <iostream>
#include <memory>
int main(int argc, const char * argv[])
{
std::unique_ptr<int> foo(new int(0));
// insert code here...
std::cout << "Hello, this is cool giri World!\n";
return 0;
}
Here is compile log:
$ clang --version
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
$ clang++ main.cpp -stdlib=libc++ -I /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/c++/4.2.1/ -I /usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/include/
main.cpp:7:10: error: no member named 'unique_ptr' in namespace 'std'
std::unique_ptr foo(new int(0));
~~~~~^
main.cpp:7:24: error: expected '(' for function-style cast or type construction
std::unique_ptr foo(new int(0));
~~~^
main.cpp:7:26: error: use of undeclared identifier 'foo'
std::unique_ptr foo(new int(0));
^
3 errors generated.
Try using clang's own standard library:
clang -std=c++11 -stdlib=libc++ main.cpp
The default is GNU's standard library (libstdc++), but the version Apple included is quite old and doesn't have C++11 support.
You can look for yourself to see what command line Xcode used.
Build your project in Xcode.
Switch to log view. The icon for it looks like a speech bubble with a couple of lines in it.
Click on the latest build.
A list of build steps will show up in the main editing area. Right-click on "Compile main.cpp" and select "Copy Transcript for Shown Results".
Paste this into your favorite text editor to see the exact command line that Xcode used to build your project.
Make sure you are invoking clang++, not clang, for both the compiler and linker.
clang++ (as compiler) needs the -std=c++11 and -stdlib=libc++ compiler flags, and clang++ (as linker) needs the -stdlib=libc++ linker flag.
thanks Everyone for suggesting me solutions which kept me going.
Finally this is what worked for me.
I uninstalled command line tools using shell script mentioned in http://www.cocoanetics.com/2012/07/you-dont-need-the-xcode-command-line-tools/
and then used
$xcode-select -switch /Applications/Xcode.app/Contents/Developer/
to set xcode version . and finally used
$xcrun clang++ main1.cpp -stdlib=libc++
to compile my code.
This worked fine. thanks!!
I'm trying to compile C++11 code that declares a variable of type std::atomic_bool. This is on Mac OS 10.8.2 with clang:
clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
clang complains about std::atomic_bool:
clang++ -c -stdlib=libc++ -msse4 -std=c++11 -Wno-unused-parameter -I. -o query.o query.cpp
In file included from query.cpp:1:
[...]
./threadutils.h:33:10: error: no type named 'atomic_bool' in namespace 'std'; did you mean 'atomic_long'?
std::atomic_bool work;
However, the same file compiles fine in an XCode project using the same compiler. So I assume I'm missing something in my manual compiler invocation.
I tried a few variations such as -std=c++0x and -std=gnu++11, to no avail.
I figured it out. Unfortunately I planted a false flag into my question: it didn't work in XCode either, I had a different version of the source file imported there.
The problem was that C++11 defines "a named type atomic_bool corresponding to the specified atomic<bool>", but clang doesn't support that.
Renaming the type from atomic_bool to atomic<bool> fixed it.
I found the same problem. In my case I resolved it by including atomic:
#include <atomic>
static std::atomic_bool varname;
After this, I could call g++ with std=c++11 on a Linux (Ubuntu) as well as compile on XCode.