I have clang++ 4.1
clang++ -v
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
I also have lldb 167.5
lldb -v
LDB-167.5
I compiled simple c++ code with this command.
clang++ testit.cpp -std=c++11 -stdlib=libc++ -g -o a
When I tried to debug it with lldb, I executed lldb ./a, set break point with b main and run.
lldb) r
Process 44582 launched: '/Users/smcho/Desktop/cpp11/lldb/a' (x86_64)
Process 44582 stopped
* thread #1: tid = 0x1f03, 0x00000001000007e8 a`main [inlined] std::__1::__vector_base<std::__1::unique_ptr<A, std::__1::default_delete<A> >, std::__1::allocator<std::__1::unique_ptr<A, std::__1::default_delete<A> > > >::__vector_base() at vector:460, stop reason = breakpoint 1.1
frame #0: 0x00000001000007e8 a`main [inlined] std::__1::__vector_base<std::__1::unique_ptr<A, std::__1::default_delete<A> >, std::__1::allocator<std::__1::unique_ptr<A, std::__1::default_delete<A> > > >::__vector_base() at vector:460
457 _NOEXCEPT_(is_nothrow_default_constructible<allocator_type>::value)
458 : __begin_(0),
459 __end_(0),
-> 460 __end_cap_(0)
461 {
462 }
463
The C++ source code is in this post: How to print out the content in vector<unique_ptr> with gdb on Mac OS X
What might be wrong?
Nothing is specifically wrong.
You are using libc++ which does heavy inlining (even at -O0, yes) - that means your code in main() is interleaved with libc++ code
The first step in your main() is to create a std::vector, and indeed you are stopped in the (inlined) constructor for std::vector (its base class, namely). It simply happens to be the first "user" instruction in your call.
You should be able to "next" over it to your user-level code.
One thing to be aware of is that you're using an older version of clang and lldb. With Xcode 4, when you run
% lldb
You're running lldb from /usr/bin which is installed by the "Command Line Tools" package (an optional download, either from developer.apple.com or from within Xcode - Preferences > Downloads tab > Components). If you instead do
% xcrun lldb
You'll be running the lldb which is included in Xcode.app -- expect to see a version like lldb-179.6. There were some important improvements to the handling of inlined functions (like those in the standard C++ library) in lldb-179 and I think it may help with what you're seeing.
You can also update to the latest Command Line Tools package from within Xcode. It isn't automatically updated by the Mac App Store updates when new Xcode updates are downloaded.
Note that in this particular case your function opens with
main() {
vector<unique_ptr<A>> v;
the inlining for this ctor on the first line of the function means you're going to see this header file even with the latest tools -- the line table output by clang doesn't give the debugger the information it needs to skip over it. If you just type next or n, you'll be on the next source line of your function.
Related
I get gdb by brew install gdb.
The source file content is:
#include <cstdio>
int main(){
int a = 10;
for(int i = 0; i< 10; i++){
a += i;
}
printf("%d\n",a);
return 0;
}
Here is the executable file named 'demo':
https://pan.baidu.com/s/1wg-ffGCYzPGDI77pRxhyaw
I compile the source file like this:
c++ -g -o demo demo.cpp
And run gdb
gdb ./demo
But, it can't work. It can't recognized the executable file.
GNU gdb (GDB) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin18.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
BFD: /Users/xxx/Codes/demo: unknown load command 0x32
BFD: /Users/xxx/Codes/demo: unknown load command 0x32
"/Users/xxx/Codes/demo": not in executable format: file format not recognized
I use file demo,its ouput is demo: Mach-O 64-bit executable x86_64
I use file ./demo,its output is ./demo: Mach-O 64-bit executable x86_64
Type c++ -v, output is :
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
run ./demo,its output is 55
type show configuration in gdb,it shows:
This GDB was configured as follows:
configure --host=x86_64-apple-darwin18.0.0 --target=x86_64-apple-darwin18.0.0
--with-auto-load-dir=:${prefix}/share/auto-load
--with-auto-load-safe-path=:${prefix}/share/auto-load
--with-expat
--with-gdb-datadir=/usr/local/Cellar/gdb/8.2/share/gdb (relocatable)
--with-jit-reader-dir=/usr/local/Cellar/gdb/8.2/lib/gdb (relocatable)
--without-libunwind-ia64
--without-lzma
--without-babeltrace
--without-intel-pt
--disable-libmcheck
--without-mpfr
--with-python=/System/Library/Frameworks/Python.framework/Versions/2.7
--without-guile
--with-separate-debug-dir=/usr/local/Cellar/gdb/8.2/lib/debug (relocatable)
Who can help me ? Thank you very much !!!
The problem is that clang-1000.11.45.2 distributed with Apple LLVM version 10.0.0 adds a new load command to o-mach executables named LC_BUILD_VERSION.
$ otool -l test.o
...
Load command 1
cmd LC_BUILD_VERSION
cmdsize 24
platform macos
sdk n/a
minos 10.14
ntools 0
...
From the apple source:
/*
* The build_version_command contains the min OS version on which this
* binary was built to run for its platform. The list of known platforms and
* tool values following it.
*/
So currently bfd (the program used by gdb to manipulate executables) is not able to interpret this command and returns the error.
As a temporary solution, you can edit the bfd sources code provides with gdb.
First, download gdb-8.0.1 sources from mirrors. Then add to gdb-8.0.1/bfd/mach-o.c the following code at line 4649 :
case BFD_MACH_O_LC_BUILD_VERSION:
break;
Finally inside gdb-8.0.1/include/mach-o/loader.h at line 189:
BFD_MACH_O_LC_BUILD_VERSION = 0x32
Don't forget to add a , at the end of the line 188 after BFD_MACH_O_LC_VERSION_MIN_WATCHOS = 0x30).
Then process a classic gdb compilation following instructions from the README :
run the ``configure'' script here, e.g.:
./configure
make
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
make install
Don't forget to sign gdb as explain here.
If you still get the (os/kern) failure (0x5) error, just run sudo gdb.
This is a temporary solution in order to wait for a fix from GNU team.
EDIT
Binutils-gdb has been updated, these changes are now implemented in commit fc7b364.
Hope It will be helpful.
I published a temporary brew formula that seems to work, while awaiting for official brew formula to be updated:
brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb
Upgrade to GDB version 8.3. Also see Issue 23728, binutils fail on macOS 10.14 (Mojave) due to unimpl in the Binutils bug tracker.
From the bug report:
I've found the root of the issue. binutils does not handle load
command 0x32 LC_BUILD_VERSION (nor 0x31 LC_NOTE, actually). They are
defined in recent LLVM versions: see
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77
Looking at the output of objdump -private-headers there is one clear
difference:
## -56,16 +56,18 ## attributes NO_TOC STRIP_STATIC_SYMS LIVE
reserved1 0
reserved2 0
Load command 1
- cmd LC_VERSION_MIN_MACOSX
- cmdsize 16
- version 10.13
- sdk n/a
+ cmd LC_BUILD_VERSION
+ cmdsize 24
+ platform macos
+ sdk n/a
+ minos 10.14
+ ntools 0
Load command 2
cmd LC_SYMTAB
cmdsize 24
LC_VERSION_MIN_MACOSX is implemented in binutils, while
LC_BUILD_VERSION is not. It is apparently new in Mojave.
I have got a good solution for me from stack overflow and I do not know why it works.
Here is the link.
I am new to macOS, and I do the following:
Codesign gdb 8.0.1 in high Sierra
Update to Mojave
gdb 8.0.1 died with BFD: /Users/xxx/Codes/demo: unknown load command 0x32
Change to gdb 8.2.1 and come across Keychain error Unknown Error -2,147,414,007.
Solve this by getting the certificate in Login then export it and import it into System(Delete it from Login if unable to import).
Finally, because of some kind of errors it still does not work and it comes with ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". Unable to find Mach task port for process-id 1510: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8)), according to how to undo codesign, something wrong still exist and the answer tells me to brew reinstall gdb, but it still does not work, I called it a day yesterday.
Finally I come across that link, I AM HAPPYY, now I am able to debug!
Hope my solution can help.
I got gdb working on Mojave by:
a) getting the latest gdb source archive (at time of writing, ftp://sourceware.org/pub/gdb/snapshots/current/gdb-weekly-8.2.50.20190212.tar.xz) - amongst other things, it adds handling for recognizing executables on Mac.
b) build gdb. I got errors for variable shadowing in darwin-nat.c so I edited the file and rebuilt.
c) follow steps in https://forward-in-code.blogspot.com/2018/11/mojave-vs-gdb.html
Voila.
(source: GDB on Mac/Mojave: During startup program terminated with signal ?, Unknown signal)
gdb 8.2 installed from Homebrew is not compatible with Mac mojave.
I have upgrade to 8.2.1. The issue should be resolved.
The answer by timotheecour above did work for me:
brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb
Then I had to generate a generate a self-signed certificate as in
https://www.thomasvitale.com/how-to-setup-gdb-and-eclipse-to-debug-c-files-on-macos-sierra/
I got past this issue on Mojave by thinning the app. GDB does not understand universal binaries. So if file myapp tells you myapp is a universal binary, try this:
lipo -thin x86_64 -output myapp-x86_64 myapp
And then
gdb myapp-x86_64
Trying to debug an application written in Qt on mac (10.6.8). Qt 4.8.6, QtCreator 3.2.0, I set up the debugger System GDB at /usr/bin/gdb and compiler gcc-4.2
I want to debug the code...
I get in the application output window
Debugging starts
Debugging has failed
Debugging has finished
(and no breakpoints were hit, nothing has started in code)
I opened the debug log window, and the only suspicious things I saw were
....
111^error,msg="Undefined command: \"python\". Try \"help\*.*
NOTE: ENGINE SETUP FAILED
State Changed From EngineSetupRequested(1) to EngineSetupFailed(2)
HANDLE RUNCONTROL FINISHED
.....
On the left, some of the commands had
109-interpreter-exec console "python sys.path.insert(1, "/Volumes/QtCreator/..."
110-interpreter-exec console "python sys.path.append("/usr/bin/data-directory/ python)"
111-interpreter-exec console "python from gdbbridge import *"
I checked that python is installed... i can type python from anywhere and get its command prompt so it is on system path...
I read something about having to sign a fsf debugger but the one I am using is not a fsf debugger ?
What can I do to debug my apps in macx ?
Edit: Tried gdb from command line, with the app as argument
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
...
This GDB was configured as "x86_64-apple-darwin"...
warning: Unable to read symbols for QtSvg.framework/Versions/4/QtSvg (file not found).
warning: Unable to read symbols from "QtSvg" (not yet mapped into memory).
warning: Unable to read symbols for QtGui.framework/Versions/4/QtGui (file not found).
warning: Unable to read symbols from "QtGui" (not yet mapped into memory).
warning: Unable to read symbols for QtCore.framework/Versions/4/QtCore (file not found).
warning: Unable to read symbols from "QtCore" (not yet mapped into memory).
warning: Unable to read symbols for QtNetwork.framework/Versions/4/QtNetwork (file not found).
warning: Unable to read symbols from "QtNetwork" (not yet mapped into memory).
Reading symbols for shared libraries .
... some warnings that .o is more recent than .dylib in dependent libs... but that I don't have to step into so I don't care...
...
warning: Could not find object file "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64/crt3.o" - no debug information available for "darwin-crt3.c".
.... done
So I type run
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff83872c00 in strlen ()
I don't know where that is (I do but really can't see it) or if it is an actual string pointer or something else...
I don't know where the breakpoints would be, the entire source is very long and contains lots and lots of files so I really don't know how I can do it with gdb from command line...
But it seems that it did get started, without complains about python ?
The warnings at start - could that mean that there is still hope, that it is possible to somehow configure gdb to run with Qt if it learns about its libraries ?
By the way... searching for the missing libraries...
QT 4.8.4 debug libraries not found on Mac OSX
I have tried to replace my debugger (in Qt) using lldb and qmake - in both cases I got an error "Unable to create a debugger engine of the type 'No engine'"
Edit: Another suggestion I read about is to recompile Qt Creator Binaries to add debug symbols... I hope that is not what I have to do because
"Note: With Qt Creator 3.2 we drop support for OS X 10.6 (Snow Leopard). The technical reason for this is that Apple does not support any kind of C++11 on that OS version. Of course that does not affect on which platforms you can run your Qt applications on. But it is not possible to run the Qt Creator 3.2 binaries on 10.6, and it also is not possible to compile Qt Creator 3.2 on 10.6 with the tool chains provided by Apple." (from release notes)
Update: I was able to find the cause of the error above (the KERN_INVALID_ADDRESS) by placing a zillion qDebug() statements... Though that was not what I am trying to accomplish, one error out of many.
I still have lots of errors... Attaching a debugger would be wonderful. I have listed the required libs for the program - they seem to exist. Not sure if they are "debug" or "release" libraries. .... But I am not trying to step through the Qt sources, so why would it matter if I have debug symbols for them ? And if they were "release" type libs, then my whole program, build in "debug", would not execute or even fail to build ? Since I am building my code in "Debug" mode and it executes, the libraries must be correct, right ?
So confusing...
QtCreator 3.2 (and a few versions before that) requires a GDB that has Python scripting enabled (or LLDB, or CDB on Windows). On Mac, Apple's GDB doesn't have Python scripting, and therefore cannot be use with Qt Creator. FSF GDB works for some projects on Mac, but in general LLDB is preferable there.
Your "GNU gdb 6.3.50-20050815 (Apple version gdb-1518)" is such an non-Python-enabled Apple build.
Background
I am trying to debug a C++ code that uses some personal dynamic libraries. I am using Mac OSX, but I am not using llvm/clang to compile my code nor the libraries. At the moment, I am using the GNU g++ compiler (4.7) provided by homebrew.
The problem
I have two choices of debuggers in this environment: the gdb version provided by Mac Developer Tools (GNU gdb 6.3.50-20050815 (Apple version gdb-1824)) and the gdb installed with homebrew (GNU gdb (GDB) 7.5.1). I would prefer to use the latter, but when using it, it shows many important variables as optimized out.
For example, this is an extract of the output of my program using gdb 7.5.1:
Breakpoint 1, MWE::Outputs (this=<optimized out>, time=<optimized out>)
at /Users/ynet/temp/mwe.cpp:203
203 cout << "example" << endl;
(gdb) p this
$1 = <optimized out>
While gdb 6.3.50 shows:
Breakpoint 1, MWE::Outputs (this=0x100601080, time=0.64300000000000046) at /Users/ynet/temp/mwe.cpp:203
203 cout << "example" << endl;
(gdb) p this
$1 = (MWE * const) 0x100601080
Both programs are identical (i.e. it's the same executable); it has been compiled with the homebrew g++-4.7 and not the llvm/clang compiler provided by Apple Developer Tools.
Unlike questions regarding the optimized out results of gdb, I have checked that I am compiling with '-O0' (my current flags are '-O0 -g -ggdb')
Question
Why do I get two different behaviors of gdb in this case and what should I do in order to use the most recent gdb version without the optimized values?
Why do I get two different behaviors of gdb in this case and what should I do in order to use the most recent gdb version without the optimized values?
It is clearly a bug for GDB to print <optimized out> for un-optimized code.
You should try to reproduce this with GDB built from trunk, create a minimal test case that shows the problem, and file a bug bugzilla.
Is it possible to debug an llvm pass using gdb? I couldn't find any docs on the llvm site.
Yes. Build LLVM in non-release mode (the default). It takes a bit longer than a release build, but you can use gdb to debug the resulting object file.
One note of caution: I had to upgrade my Linux box to 3GB of memory to make LLVM debug mode link times reasonable.
First make sure LLVM is compiled with debug options enabled, which is basically the default setting. If you didn't compile LLVM with non-default options then your current build should be fine.
All LLVM passes are run using LLVM's opt (optimizer) tool. Passes are compiled into shared object files, i.e., LLVMHello.so file in build/lib and then loaded by the opt tool. To debug or step through the pass we have to halt LLVM before it starts executing the .so file because there is no way to put a break point in a shared object file. Instead, we can put a break in the code before it invokes the pass.
We're going to put a breakpoint in llvm/lib/IR/Pass.cpp
Here's how to do it:
Navigate to build/bin and open terminal and type gdb opt. If you compiled llvm with the debug symbols added then gdb will take some time to load debugging symbols, otherwise gdb will say loading debugging symbols ... (no debugging symbols found).
Now we need to set a break point at the void Pass::preparePassManager(PMStack &) method in Pass.cpp. This is probably the first (or one of the first) methods involved in loading the pass.
You can do this by by typing break llvm::Pass::preparePassManager in terminal.
Running the pass. I have a bitcode file called trial.bc and the same LLVMHello.so pass so I run it with
run -load ~/llvm/build/lib/LLVMHello.so -hello < ~/llvmexamples/trial.bc > /dev/null
gdb will now stop at Pass::preparePassManager and from here on we can use step and next to trace the execution.
Following Richard Penningtons advice + adding backticks works for me:
gdb /usr/local/bin/opt
then type
run `opt -load=/pathTo/LLVMHello.so -hello < /pathTo/your.bc > /dev/null`
Note: I would have commented, but couldn't (missing rep.)
I wrote a very simple Qt program here:
int main(int argc, char* argv[])
{
QApplication app(argc, argv);
QTableView table(&frame);
table.resize(100, 100);
table.show();
return app.exec();
}
And when I try to set a breakpoint where the table gets clicked, I get this error from gdb:
(gdb) symbol-file /usr/lib/libQtGui.so.4.4.3.debug
Load new symbol table from "/usr/lib/libQtGui.so.4.4.3.debug"? (y or n) y
Reading symbols from /usr/lib/libQtGui.so.4.4.3.debug...done.
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)'
Breakpoint 1 at 0x5fc660: file .moc/release-shared/moc_qabstractitemview.cpp, line 313.
(gdb) run
Starting program: ./qt-test
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x5fc660: Input/output error.
Does anyone know why the breakpoint can't be inserted?
Don't use the gdb command symbol-file to load external symbols. The breakpoint addresses will be wrong since they're not relocated.
Instead, put a breakpoint in main, run the program, and then set your breakpoint:
gdb ./program
GNU gdb 6.8-debian blah blah blah
(gdb) br main
Breakpoint 1 at 0x80489c1
(gdb) run
Starting program: ./program
Breakpoint 1, 0x080489c1 in main ()
(gdb) br 'QAbstractItemView::clicked(QModelIndex const&)'
Breakpoint 2 at 0xb7d24664
(gdb) continue
Continuing.
Then make your breakpoint happen.
Make sure to specify the parameter list in the function you want to set a breakpoint in, without the names of those parameters, just their types.
The actual error:
Error accessing memory address 0x5fc660: Input/output error.
Can be caused by 32/64 bit mixups. Check, for example, that you didn't attach to a 32-bit binary with a 64-bit process' ID, or vice versa.
If you want to automatically break in main without setting a breakpoint you can also use the start command.
If you need to provide any arguments to the program you can use:
start argument1 argument2
OK for me I got this when building with mingw-w64 (native or cross compiler).
I'm not sure what the exact problem was, but if I build it using gcc mingw-w64 i686-5.1.0-posix-sjlj-rt_v4-rev0 then it creates (finally) debuggable builds. Otherwise
(gdb) break main
...
(gdb) r
...
Cannot insert breakpoint 1.
Cannot access memory at address 0x42445c
<process basically hangs>
message 19 times out of 20, though sometimes it did actually work (very rarely).
gdb 7.8.1 and 7.9.1 seemed to be able to debug the created exe. So it's probably not the version of gdb that makes a difference.
My current theory/suspect is either it was the version of gcc or possibly the sljl vs. dwarf2 "aspect" to the compiler [?] (i686-492-posix-dwarf-rt_v3-rev1 didn't work, and cross compiling with some form of gcc 4.9.2 didn't either). Didn't try other versions of gcc.
update: newer gcc (5.1.0) but cross compiling I still got this failure. The cause in this case turned out to be a dependency library that my build (FFmpeg) was using by linking against (libgme in this case) which is exporting a few errant "shared" symbols (when I am building a static executable). Because of this, "shared" builds brake (https://trac.ffmpeg.org/ticket/282) and somehow it screws up gdb as well. For instance possibly linking against SDL can do this to you as well. My thought is possibly an ld bug [?]