GDB throws "Illegal Instruction" when linking -lcurl - gdb

The program compiles and executes perfectly, it's just GDB Debugger which break right at the start of the execution, emerging the following dialog:
I can just press Continue and the program will run properly, but it's so annoying to have to do this in every execution.
I am Cross-Compiling remotely to Linux-ARM with this MVS extension and it only happens when I link -lcurl
I have tried to disable every checkbox below "Break When Thrown" in Exception Settings, I though that at least I wouldn't be bothered anymore, but it still emerging the dialog.

I noticed that it wasn't MVS, it was remote GBD on linux instead, since I tried to debug my program from CLI and I got the same issue:
root#server:/.../Debug# gdb --exec=myapp
GNU gdb (Raspbian 7.7.1+dfsg-5+rpi1) 7.7.1
Copyright (C) 2014 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 "arm-linux-gnueabihf".
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) run
Starting program: /.../Debug/myapp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Cannot access memory at address 0x0
Program received signal SIGILL, Illegal instruction.
0x76a5fde8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb) continue
Continuing.
Hello World
[Inferior 1 (process 5879) exited normally]
(gdb)
After that, I quickly found a workaround to make gdb ignore this signal so it wouldn't bothered me anymore stopping the proccess:
I just added handle SIGILL nostop to /etc/gdb/gdbinit

Related

gdb commands on bin file does not work for my binary file

I'm trying to use gdb to revese engineer a .bin file. I've tried following a bunch of guides, but every single thing I do seems to fail.
First I just open the file with gdb:
$ gdb impossible_password.bin
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 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 "apropos word" to search for commands related to "word"...
Reading symbols from impossible_password.bin...
(No debugging symbols found in impossible_password.bin)
I try to disassemble main:
(gdb) disassemble main
No symbol table is loaded. Use the "file" command.
Ok, strange, this worked in the video I saw about it. What am I doing wrong here?
Also, I saw another video, where a guy started the file, and could set breakpoints, using location id's from ghidra. I Also wanted to try this:
$ gdb impossible_password.bin
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 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 "apropos word" to search for commands related to "word"...
Reading symbols from impossible_password.bin...
(No debugging symbols found in impossible_password.bin)
(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Temporary breakpoint 1 (-qualified main) pending.
Starting program: /home/ask/Notes/ethHack/wetransfer-85179d/Export/impossible_password.bin
* b *00400961
[b]
[Inferior 1 (process 29475) exited with code 01]
(gdb)
Where setting the breakpoint just fails. And I can see absolutely no values inside the file.
What am I doing so absolutely wrong? I really just wanna get started and look at some values inside this file
EDIT:
Here is the info about the file in question:
$ file impossible_password.bin
impossible_password.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ba116ba1912a8c3779ddeb579404e2fdf34b1568, stripped
Your .bin file is fully stripped. This means there are no symbols in it, and every command which requires symbols (such as break main and start) will fail.
You can only set breakpoints on addresses.
Assuming 0x0400961 is indeed address of main, this should work:
(gdb) break *0x0400961
(gdb) run

gdb always quit after press any key

I checked out the gdb source and compiled successfully with MinGW. When I run the output file gdb.exe, I cannot input anything, any key press would cause it quit:
aj#TERRAN E:\
$ gdb --data-directory=E:\gdb_build\gdb\gdb-7.11\gdb\data-directory
GNU gdb (GDB) 7.11
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 "--host=i686-pc-mingw32 --target=arm-linux-androideabi".
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) quit
aj#TERRAN E:\
$
I didn't input the last quit, I just hit the space and it quits.
I downloaded another prebuilt gdb which works fine, but it doesn't support python, so I need to build it myself.
But I tried the tui mode with gdb -tui, it works fine, I can type commands.
Why does non-tui-mode quit?
This is a bug of gdb 7.12, 7.11.1 works just fine.
The older versions of GDB have this bug when building them from sources on Windows. I have this problem with a custom GDB 7.6.1 built with MSYS2.
The problem appears when the GDB is linked with ncurses library. In this case, the function getch() is taken from ncurses and returns EOF because there's no curses window. It is called from readline/input.c:rl_getc().
The latest sources have this fixed and call _getch() from the standard library. This simple fix ends with backspace key not deleting characters. So, there are more fixes in readline to fix that too.
More info: https://www.mail-archive.com/bug-readline#gnu.org/msg01203.html
https://gdb-patches.sourceware.narkive.com/A7CT0KH0/enabled-tui-mode-on-msys2
A simple workaround to build an old version is to disable TUI mode with --disable-tui configure option. This will build GDB without ncurses dependency and not expose this bug.

Configuring VS Code with Gdb

I am using Vs Code in Linux. Is it possible to configure Gdb with Code so that I can use the gui for debugging for C/C++ programs.
There is an extension called debug you can install using ext install debug. Im the author of the extension and it supports debugging native applications using GDB. Just follow the README in there and it should be very easy to setup. If you want to build before debugging, just add a preLaunchTask to the config and create a build task that compiles your application.
EDIT: Sorry, strike that since it's just Homebrew's gdb not being signed in Yosemite: http://sourceware.org/gdb/wiki/BuildingOnDarwin
Installed your extension, defined the .json runner and got a terminal stating:
"&"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"...
When typing GDB commands, I'm told that the process is running (despite having set the breakpoint in the editor, red dot).
Then when I close the floating terminal (outside the VSCode builtin one):
GNU gdb (GDB) 7.11
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-apple-darwin14.5.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/>.
=cmd-param-changed,param="confirm",value="off"
=cmd-param-changed,param="output-radix",value="16"
=cmd-param-changed,param="prompt",value="\001\e[;31m\002gdb-peda$ \001\e[0m\002"
=cmd-param-changed,param="history expansion",value="on"
=cmd-param-changed,param="history save",value="on"
=cmd-param-changed,param="disassembly-flavor",value="intel"
=cmd-param-changed,param="follow-fork-mode",value="child"
=cmd-param-changed,param="step-mode",value="on"
=cmd-param-changed,param="print pretty",value="on"
ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". Unable to find Mach task port for process-id 65326: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
The program '/Users/romanvg/dev/bcftools/bcftools' has exited with code 42 (0x0000002a).
:(

gdb error in re-settings breakpoint (cannot access memory)

I am trying to get gdb to set a breakpoint in pcbsd10 (freebsd10).
I have compiled my code with debug symbols, and here is the output from gdb
GNU gdb (GDB) 7.7
Copyright (C) 2014 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-freebsd10.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"...
Reading symbols from tor...done.
(gdb) break config.c:3626
Breakpoint 1 at 0xfde72: file src/or/config.c, line 3626.
(gdb) run
Starting program: /usr/home/jon/swdev/apps/tor/src/or/tor -f /home/jon/torrc
Error in re-setting breakpoint 1: Cannot access memory at address 0xfdb90
Error in re-setting breakpoint 1: Cannot access memory at address 0xfdb90
...
And my code continues to run without stopping at the breakpoint.
What is going on here? How can I get more insight into why gdb is failing?
You are possibly looking at this GDB bug.
Although it looks like GDB 7.7 should already have a fix, you may want to try 7.7.1.
Alternatively, build your binary as a non-PIE binary (remove -fPIE from the Makefile).

Strange errors trying using gdb remotely: What am I doing wrong?

I've got a 64-bit remote machine, anvil, and a 32 bit desktop.
I make a program called hello.c
and on anvil I compile it with
$ gcc -ggdb -o hello hello.c
It will run and debug fine on anvil.
But I'd like to debug it from my desktop (so I can use the debugger through emacs)
So :
$gdbserver anvil:24000 hello
Process hello created; pid = 10991
Listening on port 24000
But then on the desktop, I try to connect remotely, and all I get is strange errors
There's some sign of connectivity: after I type target remote anvil:24000 the other end prints 'Remote debugging from host 10.17.20.149', which is my desktop address.
Here's a transcript:
jla#jaspden-desktop$ gdb hello
GNU gdb (GDB) Fedora (7.2-51.fc14)
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 "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/jla/myco/chip_test/hello...done.
(gdb) target remote anvil:24000
Remote debugging using anvil:24000
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0x0000003ed0100a80 in ?? ()
(gdb) b main
Breakpoint 1 at 0x4004b7: file hello.c, line 6.
(gdb) run
The "remote" target does not support "run". Try "help target" or "continue".
(gdb) continue
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000004003f6 in _start ()
(gdb)
Does anyone know what I'm doing wrong?
Does anyone know what I'm doing wrong?
gcc -ggdb -o hello hello.c
This likely produces a 64-bit binary (though we can't tell for sure from what you've provided so far). As I said before, it doesn't matter that anvil is a 64-bit machine. What matters is what binary you are trying to debug.
What does file hello say?
GNU gdb (GDB) Fedora (7.2-51.fc14)
...
This GDB was configured as "i686-redhat-linux-gnu".
That's a problem: if hello is a 64-bit binary, then you can't debug it with this version of gdb. You will need to build a new version, configured with --host=i686-linux and --target=x86_64-linux.