I installed gdb because it was telling me that gdb was not found when I tried to run my .asm file. Since it got installed and I shouldn't expect 'gdb not found' I ended up with the whole copyright license and stuff whenever I run my code. Did I install it incorrectly? I used "$ sudo apt-get install gdb" in terminal.
rm: cannot remove '*.o': No such file or directory
rm: cannot remove '*.lis': No such file or directory
rm: cannot remove '*.out': No such file or directory
compile driver.cpp using the g++ compiler standard 2017
compile isFloat.cpp using the g++ compiler standard 2017
Assemble compare.asm
Link object files using the gcc Linker standard 2017
Run the Float Program:
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 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-linux-gnu".
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 <RET> for more, q to quit, c to continue without paging--q
Quit
Script file has terminated.
Related
With the pristine gdb (Debian 8.2.1-2) while debugging RefPerSys (GPLv3+, on gitlab) commit ec4ab756d302056cace0b on my Linux/x86-64/Debian Sid AMD2970WX desktop, I am reproducibly getting
rimski.x86_64 ~/refpersys 14:39 .0 % gdb --args ./refpersys --object-tinybenchmark1
GNU gdb (Debian 8.2.1-2) 8.2.1
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-linux-gnu".
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"...
Reading symbols from ./refpersys...done.
warning: File "/home/basile/refpersys/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /home/basile/refpersys/.gdbinit
line to your configuration file "/home/basile/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/basile/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
What is the magic to have my ./.gdbinit digested by such a gdb invocation without diagnostics? That .gdbinit contains:
# file refpersys/.gdbinit
# GPLv3+ licensed
add-auto-load-safe-path ./.gdbinit
break abort
break rps_fatal_stop_at
set max-value-size 67108864
I could (and did that in the past) rebuild gdb from its source code. But today, I am lame, and prefer focusing on my bugs.
FWIW
(gdb) show configuration
This GDB was configured as follows:
configure --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--with-expat
--with-gdb-datadir=/usr/share/gdb (relocatable)
--with-jit-reader-dir=/usr/lib/gdb (relocatable)
--without-libunwind-ia64
--with-lzma
--with-babeltrace
--with-intel-pt
--disable-libmcheck
--without-mpfr
--with-python=/usr (relocatable)
--without-guile
--with-separate-debug-dir=/usr/lib/debug (relocatable)
--with-system-gdbinit=/etc/gdb/gdbinit
Just as the warning says when you launch gdb:
To enable execution of this file add
add-auto-load-safe-path /home/basile/refpersys/.gdbinit
line to your configuration file "/home/basile/.gdbinit".
It seems like you've misunderstood and added the line into the .gdbinit file within your repo but it needs to go into your home directory.
If the .gdbinit file doesn't yet exist in your home directory, you can create it and only add the needed line above, and it should work.
I'd like to execute following commands during gdb start. I've put them in file in my /root directory.
> cat /root/gdbst.gdb
file /root/centos-6.3-x86_64/abc
dir /root/centos-6.3-x86_64/dir/abcdir
target extended-remote 192.168.0.180:1234
Then I run
> gdb -x /root/gdbst.gdb
gdb is started but no command executed.
Here is what I get
root#ubuntu:~# gdb -x /root/gdbst.gdb
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 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-linux-gnu".
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"...
(gdb)
And
-rwxrwxr-x 1 root root 236 Jan 24 03:16 gdbst.gdb
Doing so from gdb command prompt
(gdb) source -v /root/gdbst.gdb
+file /root/centos-6.3-x86_64/abc
+dir /root/centos-6.3-x86_64/dir/abcdir
+target extended-remote 192.168.0.180:1234
Runnign all these commands manually do what I want: gdb sets file and dir and connects to remote gdbserver.
But why it ignores command file?
Seems that problem was with remote side. gdbserver had been started, but it doesn't respond to connections as it should. So gdb executed commands silently, and last command doesn't connect to remote gdb, but silently.
Restarting gdbserver solved the problem.
But seems that it should be restarted any time I'd like to reconnect...
I'm using Qt Creator 3.2.1 and gdb 7.6.2 (powerpc64-fsl-linux-gdb from QorIQ SDK 1.8) for debugging cross compiled applications.
On my ppc64 test machine (Yocto) I run gdbserver: gdbserver :666 /path/to/myapp
Then I connect using Qt Creator on my x86_64 dev machine (Debian) to gdbserver. I've specified Kit (sysroot is /opt/fsl-networking/QorIQ-SDK-V1.8/sysroots/ppc64e6500-fsl-linux), the toolchain gdb, etc... This works so far. I can debug any application.
But if my application links dynamically to a library and I want to debug this library (/path/to/libmylib.so), gdb within Qt Creator fails to step into the breakpoints of mylib.
What I want to do with Qt Creator is like this:
Yocto: start the gdbserver
Debian: run powerpc64-fsl-linux-gdb /path/to/myapp and enter
set solib-search-path /path/to/mylib/
target remote 192.168.120.211:666
break MyLibraryFunctionIWantToDebug
run
c
Log:
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 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 "--host=x86_64-fslsdk-linux --target=powerpc64-fsl-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /path/to/myapp...done.
(gdb) show solib-search-path
The search path for loading non-absolute shared library symbol files is .
(gdb) set solib-search-path /path/to/mylib/
(gdb) show solib-search-pat
The search path for loading non-absolute shared library symbol files is /path/to/mylib/.
(gdb) target remote 192.168.120.211:666
Remote debugging using 192.168.120.211:666
(gdb) break MyLibraryFunctionIWantToDebug
Breakpoint 1 at 0x10001088: file /path/to/myapp/myapp.c, line 196.
(gdb) run
The "remote" target does not support "run". Try "help target" or "continue".
(gdb) c
...
Research so far:
gdb has a bug in version 7.4 (I'm using 7.6.2 right now)
I can put the set solib-search-path /path/to/mylib/ command into .gdbinit. In Qt Creator every .gdbinit file is ignored. I've tried multiple locations, e.g. ~/.gdbinit, /path/to/myapp/.gdbinit, command line arguments option in Qt creator: -x ~/.gdbinit, Tools > Options > Debuggers putting the command into every additional field. None works :-(
I'm not alone with my question, see here or here
Any ideas how to cross debug with gdb in Qt Creator when using shared libraries?
Maybe it's changed with QtCreator 3.6 (what I'm using), but if I put the set solib-search-path command in the "Additional Attach Commands" fiend and only that field, I got it to work.
Granted, my case may not be fully applicable to yours as it's not a full cross-compilation, but a case of running GDB on a different version of Linux than my remote target runs.
abijith bufferOverFlow $ gdb a.out
GNU gdb (GDB) 7.6
Copyright (C) 2013 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-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/abijith/Project/Security/bufferOverFlow/a.out...done
(gdb) r
Starting program: /home/abijith/Projec2qt/Security/bufferOverFlow/a.out
warning: no loadable sections found in added symbol-file system-supplied
SO at 0x7ffff7ffd000
I wrote a simple program which prints a string and returns. I was able to execute it directly, by typing "./a.out". But when I run it in gdb the error mentioned above happens. I tried compiling the code using the "-g" flag and without using it. Both time it gave the same result. Can anyone help me with this issue??
That message,
warning: no loadable sections found in added symbol-file system-supplied
SO at 0x7ffff7ffd000
is a warning that does not prevent GCC from running a.out; at least, it should not.
It is saying that there's a dynamically loaded object used by a.out that is missing symbols. Nothing about a.out itself.
You can try to build a.out as a static executable; like this:
gcc -static a.c
Obviously, add any other compiler arguments needed.
As a static executable, you won't get that warning from GCC. Those symbols may still be missing, but it should not affect execution of the program.
It appears this is a bug in glibc or gdb (depending on where you want to put the blame). It is apparently harmless - gdb will work fine.
It is caused by some magic the Linux kernel performs on binaries it runs. For details, see Debian bug report 738702 and the original gdb bug report 13097.
There is a patch to fix this, which Debian applied recently, so the problem no longer occurs with GDB 7.7.1 on Debian.
How to tell gdb run this way: gdb java -cp /var/tmp/Test.jar myjava.class
$ gdb /var/tmp/Test.jar 14940
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
"/var/tmp/Test.jar": not in executable format: File format not recognized
Attaching to process 14940
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
/var/tmp/14940: No such file or directory.
(gdb) run
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.
(gdb)
$ gdb -p 14940
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 14940
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
(gdb) run
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.
(gdb)
From GDB's point of view, the program here is java. It accepts many arguments (-cp , classname etc)
You can set arguments using set args
http://www.delorie.com/gnu/docs/gdb/gdb_19.html