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.
Related
I am using Buildroot 2018.02 for an IMX6 board and the Linaro external toochain 2017.11 based on GCC 2017.11 (GCC 7.2.1)
Now i am adding some debug tools such as gdbserver on the target.
Everything is OK if i use the option "Build cross gdb for the host" and selecting the gdb debugger version 7.11.x for the host along with the gdbserver (BR2_PACKAGE_GDB_SERVER) in the "Target Packages > Debugging,.." menu. There are also other version of gdb available in Buildroot such as 7.12.x and 8.0.x.
However, for an external toolchain the recommended way is :
https://github.com/mbats/eclipse-buildroot-bundle/wiki/Tutorial-:-How-to-debug-a-remote-application-%3F which means to activate only the "Copy gdb server to the Target" option in Buildroot (although the post is a bit old)
I have noticed that the BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM description says that Linaro gdb is based on gdb 8.0 so a newer version that the one i am using (7.11.x).
But when i do that, i have the following message on the target board :
# gdbserver
-sh: gdbserver: not found
despite the following :
# which gdbserver
/usr/bin/gdbserver
gdbserver binary is on the target.
How to fix this in Buildroot ?
Moreover i have two additional questions :
Does it really matter to have the Linaro toolchain gdb instead of
the gdb 7.11.x that works "out of the box" in my case ?
If i don't use the Linaro gdb then should i use the gdb version
8.0.x ( because the Linaro version is based on the 8.0 of GDB ) ?
Thank you for your help.
The gdbserver binary in the Linaro 2017.11 toolchain is broken: it requests /usr/lib/ld.so.1 as the program interpreter (see below), but that program interpreter doesn't exist.
You can try to create a symlink /usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 (add that to your filesystem overlay if it works). Alternatively, you can specify the program interpreter explicitly by putting it before the executable, i.e. /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver.
The "program interpreter" is a parameter of an ELF file that points to a program that is used to load the ELF file into memory and to start executing it. The main responsibility of the program interpreter is to find and load the dynamic libraries that the program needs. Thus, it is usually called the "dynamic library loader", or ld.so. It is built and installed together with the toolchain - specifically, the standard C library (glibc). When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). Apparently Linaro did something really peculiar to end up with a wrong program interpreter in the gdbserver executable.
# gdbserver
-sh: gdbserver: not found
depsite the following :
# which gdbserver
/usr/bin/gdbserver
Most likely:
The gdbserver is a dynamically linked binary, and
The ELF interpreter that this binary is linked to use is not present on the target system.
Use readelf -l /usr/bin/gdbserver | grep -i interpreter to find out what runtime loader this gdbserver requires. Verify that that file is not present on the target. Copy it to the target and enjoy.
I installed GDB through Homebrew for Mac, and I'm currently using GDB Version 7.10. I set a breakpoint inside an application, and when it finally stopped I tried executing an expression from GDB. Here's what I experienced:
(gdb) expr -- hasValue = YES
Could not load libcc1.so: dlopen(libcc1.so, 2): image not found
Any ideas?
If you want to use the compile feature in gdb, then you also need the correct version of GCC and the libcc1 plugin (which is part of the GCC source tree and is built alongside GCC).
It sounds like you don't have that.
A simpler way to evaluate expressions in gdb is to use print (or one of its aliases, like set variable). So for example:
(gdb) print hasValue = YES
This approach relies on gdb's built-in expression parser and doesn't require any external library or compiler.
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.
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.
Using MacPorts i have just installed arm-elf-gcc on to my MacBook Pro. This worked flawlessly and all seems to run fine.
However, after compiling a simple hello world test program in C and C++ and trying to run either on the target board (an ARM9 based board running Debian Linux) they immediately seg fault.
I'm a bit stuck as how to go about debugging this, as the target board has limited tools available and no gdb. I have successfully built and run other code using a Linux hosted cross compiler so it should work.
Any ideas?
Following the suggestion I have built and run gdbserver, I get the following in gdb on the host:
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
I thought it may be a problem with the standard c libs so I removed any calls and have just an empty main that return 0, it is compiled with -Wall -g hello-arm.cpp -static. As a test I compiled the same source with a Linux hosted cross compiler and it runs and exits fine. The only difference I can see is the that Linux compiled version is over twice the size and the difference in output from the file command:
arm-elf-gcc: ELF 32-bit LSB executable, ARM, version 1, statically linked, not stripped
arm-*-linux: ELF 32-bit LSB executable, ARM, version 1, statically linked, for GNU/Linux 2.4.18, not stripped
The usual method of debugging in this situation is to run gdbserver on the target board, and connect to it (via ethernet) with gdb running on a host computer.
Alternately, you could try comparing the assembly in a Mac-compiled "Hello World" program and a (working) Linux-compiled one to see what's different.
After digging around for a couple of days I am starting to understand a bit more about embedded compilers. I wasn't really sure of the difference between arm-elf-gcc installed via MacPorts and the arm-unknown-linux toolchain I had installed on my Linux box. I just came across a pdf titled "An introduction to the GNU compiler" which contains the following paragraph:
Important: Using the GNU Compiler to
create your executable is not quite
the same as using the GNU Linker,
arm-elf-ld, yourself. The reason is
that the GNU Compiler automatically
links a number of standard system
libraries into your executable. These
libraries allow your program to
interact with an operating system, to
use the standard C library functions,
to use certain language features and
operations (such as division), and so
on. If you wish to see exactly which
libraries are being linked into the
executable, you should pass the
verbose flag
-v to the compiler.
This has important implications for
embedded systems! Such systems do not
usually have an operating system.
This means that linking in the system
libraries is almost always
meaningless: if there is no operating
system, for example, then calling the
standard printf function does not make
much sense.
So when I get back to my dev machine later I will determine the libraries linked in with the Linux build and add them to the arm-elf-gcc build.
I'll update this when I have more information but I just want to document my findings in case any one else has these problems.