This gdb was installed via Homebrew on my OSX.
I wonder why gdb doesn't work on this file(I was playing pwn)on my OSX, while I can run it on Kali linux through VirtualBox.
I saw some people mentioned "Apple version gdb", is that the problem?
And how do I solve this?
I searched for answer quite a while and even asked my proffessor, please give me a hand!
➜ file bof
bof: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.24,
BuildID[sha1]=ed643dfe8d026b7238d3033b0d0bcc499504f273, not stripped
➜ gdb bof
GNU gdb (GDB) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
.
.
.
"/Users/me/Desktop/test/bof": not in executable format: File format not recognized
(gdb)
This gdb was installed via Homebrew on my OSX.
...
bof: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.24,
There are many ways to configure gdb. The default -- if you don't pass any special options to configure -- is to configure in just what is needed for the host platform.
In this case, probably what has happened is that your gdb is configured for OSX -- meaning Mach-O and not ELF -- and so gdb can't read ELF files. You can test this theory by typing set gnutarget <TAB> <TAB> at the gdb prompt (the tabs will cause completion, which is the only way I know of to list what was compiled in here). Alternatively, you can try show configuration, though that just says what options were passed to configure, and so it needs interpretation.
One simple way to get out of this is to reconfigure with --enable-targets=all. Then gdb will be able to read ELF files and other things as well.
Related
Problem
I'm trying to debug this Rust program using rust-gdb, but I can't seem to get GDB to work properly:
/home/a/tmp/foo(HEAD)
09/19/2021 09:57:23.114 AM> rust-gdb -q target/debug/foo
Reading symbols from target/debug/foo...
(gdb) b hello
Breakpoint 1 at 0x7a44: file src/main.rs, line 2.
(gdb) run
Starting program: /home/a/tmp/foo/target/debug/foo
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x7a44
(gdb)
I also tried setting the breakpoint using b src/main.rs:2 as well as running just gdb instead of the Rust wrapper rust-gdb both of which resulted in the same outcome. Am I doing this properly?
System Information
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:48.200 AM> uname -a
Linux a 5.13.15_1 #1 SMP Fri Sep 10 16:52:33 UTC 2021 x86_64 GNU/Linux
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:51.291 AM> rustc --version
rustc 1.55.0 (c8dfcfe04 2021-09-06)
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:53.955 AM> gdb --version
GNU gdb (GDB) 10.2
Copyright (C) 2021 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.
I managed to get it working by uninstalling the installed gdb (which was obtained from the Nixpkgs repository) and replacing it with gdb from the Void Linux musl repository. I suspect the gdb from Nixpkgs was built with glibc and is incompatible with the compiled Rust program which was compiled to use musl instead. Usually, the Bedrock Linux userspace that I use allows me to use programs built with different C libraries together, but in this case I guess I needed GDB to be using the same C library as the thing it's trying to debug.
I've tried to configure GCC 9.3.0 to produce executable files for DOS. However, for a simple "Hello world!" program in C, it outputs:
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0xd6): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x10b): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x131): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x141): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x3d4): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(getenv.o):getenv.c:(.text+0x4): more undefined references to `_environ' follow
collect2: error: ld returned 1 exit status
djgpp-gcc -v outputs:
Using built-in specs.
COLLECT_GCC=djgpp-gcc
COLLECT_LTO_WRAPPER=/home/teo.samarzija/djgpp-9.3.0/libexec/gcc/djgpp/9.3.0/lto-wrapper
Target: djgpp
Configured with: ../gcc-9.3.0/configure --target=djgpp --prefix=/home/teo.samarzija/djgpp-9.3.0 --enable-languages=c,c++,objc,ada,fortran,go
Thread model: single
gcc version 9.3.0 (GCC)
I've also compiled the newest version of the GNU linker and GNU Assembler, they output as their versions:
GNU ld (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
and
GNU assembler (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `djgpp'.
Any idea what I am doing wrong? Have GCC or GAS or GLD stopped supporting DOS some time in the past? I suppose not, because they compile for DOS as a target without warning about that.
I only stumbled on this question because of a more recent Stackoverflow question you asked about some code that didn't run properly in 32-bit Windows 10 inside an NTVDM virtual DOS session.
The problem is that you have not properly built a DJGPP cross compiler and all the needed components. You do not show us what commands you use for the build process and which versions of the dependencies were used and where they came from.
1st thing you need to do is build a DJGPP cross compiler. There are some people who maintain scripts to do just that. One build environment/script in particular I have used successfully is from the user Andrew Wu on Github. It is very simple to use. It appears you are using a Unix type environment based on the output you have shown us. Since you managed to build DJGPP (albeit one that doesn't work) I will assume you have all the necessary build tools installed already. First retrieve the scripts with:
git clone https://github.com/andrewwutw/build-djgpp
Change into the project directory with:
cd build-djgpp
Review the README.md file! It tells you what versions are supported by the script, build requirements for the type of OS you are on etc. At present they support versions all the way to 10.1.0. If you have everything needed choose a version to build (I'll use 9.3.0 since it is the version you are using) and then start the build. You will have to build as root or use sudo as it installs to directory /usr/local/djgpp
./build-djgpp.sh 9.3.0
It will take a while but when finished it should be installed and ready to use. The naming convention is a bit different than prefixing the commands with djgpp-. This script builds things with a more complete target prefix i586-pc-msdosdjgpp-
To add it to your path and set up other environment variables use:
. /usr/local/djgpp/setenv
If you wish it to be done each time you are logged in add that line to your shell login script. For BASH that is in the file ~/.bashrc
Create a file called hello.c containing:
#include<stdio.h>
int main()
{
printf("Hello, world!\n");
}
Compile it to a file called hello.exe:
i586-pc-msdosdjgpp-gcc -O3 -Wall -Wextra hello.c -o hello.exe
Assuming you have a DPMI host installed (like CWSDPMI.EXE), hello.exe should run in MS-DOS, FreeDOS, DOSBox, a Windows NTVDM session etc. When run it should display:
Hello, world!
If you don't wish to build from scratch, Andrew Wu has a number of pre-built packages for a number of the latest DJGPP releases. Platforms they are available for are MacOS, Linux 32, Linux 64, MinGW, and a MinGW standalone version that doesn't need the MinGW environment to run.
I am trying to cross-compile Linux for QEMU (RV64G ISA, lp64d ABI, Virt machine) using Buildroot. But apparently, GDB has been removed from buildroot version I'm using (2019.08), and is listed under the legacy list.
My objective is to be able to run RISC-V Linux application (in user-mode and softmmu) and with GDB debugging. I was able to build and run RISC-V apps using QEMU in both modes. But I didn't find a way to generate GDB like the other host utilities. Any ideas on how to do that?
A possible procedure for building a riscv64-linux-gnu-gdb from scratch would be :
PREFIX=$(pwd)/gdb-8.3.1-riscv64-linux-gnu
wget ftp://ftp.gnu.org/gnu/gdb/gdb-8.3.1.tar.xz
tar Jxf gdb-8.3.1.tar.xz
mkdir gdb
cd gdb
../gdb-8.3.1/configure --program-prefix=riscv64-linux-gnu- -with-tui --target=riscv64-linux-gnu --prefix=${PREFIX}
make all install
cd -
Build artifacts will located in $(pwd)/gdb-8.3.1-riscv64-linux-gnu:
ls -gG gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb
-rwxr-xr-x 1 80395824 Sep 26 14:16 gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb
gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb --version
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 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.
If you don't want to build GDB with the TUI interface, remove --with-tui from the ./configure command.
I hope this helps.
gdb has certainly not been removed from Buildroot! However, back when the RISC-V support was added in Buildroot, the gdb support was not included, and therefore BR2_PACKAGE_HOST_GDB_ARCH_SUPPORTS depends on !BR2_riscv, which hides gdb when the RISC-V architecture is selected.
So one would need to see if there is an upstream version of gdb that supports RISC-V, and if there is, remove the !BR2_riscv dependency, and add the appropriate dependencies to prevent the user from selecting older gdb versions that don't have RISC-V support.
I have a core dump file that has been generated by an erlang application and would like to analyze. This is my first time using gdb. I installed gdb but no luck running it with the executable and the core dump file.
I give gdb the executable and the core dump as
gdb erts-5.9.3/bin/beam.smp core
When I run that, I get,
GNU gdb (GDB) 7.9
Copyright (C) 2015 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-darwin15.4.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 erts-5.9.3/bin/beam.smp...(no debugging symbols found)...done.
"/Users/sad/projects/core" is not a core dump: File format not recognized
Any help ? Thanks!
This GDB was configured as "x86_64-apple-darwin15.4.0".
"/Users/sad/projects/core" is not a core dump: File format not recognized
$ file core
/Users/sad/projects/core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), ...
Mac OS does not use ELF file format. We can safely assume that this core came from some other system, not the one you are trying to analyse it on.
It is still possible to analyse that core on the Mac OS system, but you need:
a cross-gdb (i.e. one that can run on Mac OS host, but can deal with ELF files for your target; it is likely that you'll have to build such GDB yourself) and
(unless you have a fully-static executable), you need complete set of shared libraries from the host on which the crash happened. See this answer.
In general, it is much easier to do the post-mortem analysis on the host where the crash happened.
I have this kind of message when I start gdb :
$ gdb a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov 3 21:59:02 UTC 2011)
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 .
warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a(array_type_info.o)" - no debug information available for "../../../../gcc-4.7.0/libstdc++-v3/libsupc++/array_type_info.cc".
warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a(bad_alloc.o)" - no debug information available for "../../../../gcc-4.7.0/libstdc++-v3/libsupc++/bad_alloc.cc".
It seems that I need to fetch again the libstdc++ but how with macports?
This is one of several problems caused by the special Unix environment installed by Apple as part of Xcode. If you need a newer version of gcc than the one installed by Xcode, make sure you also install a newer version of gdb, or you will get the problems described above. You also need to make sure that your environment actually calls the macport versions of both and not the default Xcode versions.
Just installing gcc from macports will NOT make the command 'gcc' invoke the version of gcc installed by macports. Similarly, 'gdb' will not invoke the version of gdb installed by macports. The versions installed by macports have the paths '/opt/local/bin/gcc-mp-4.6' and '/opt/local/ggdb' or something similar dependent on the version number of gcc. Note that it is 'ggdb' and not 'gdb'.
One solution is to always explicitly invoke the right version by giving the entire path. Another is to replace the default gcc and gdb locations with links to the macports versions (this may cause problems with Xcode possibly). The default locations are '/usr/local/bin/gcc' and '/usr/bin/gdb'. The default bash shell will look in those locations regardless of your path settings.
http://gcc.gnu.org/gcc-4.5/changes.html says
GCC now generates unwind info also for epilogues. DWARF debuginfo generated by GCC now uses more features of DWARF3 than before, and also some DWARF4 features. GDB older than 7.0 is not able to handle either of these, so to debug GCC 4.5 generated binaries or libraries GDB 7.0 or later is needed. You can disable use of DWARF4 features with the -gdwarf-3 -gstrict-dwarf options, or use -gdwarf-2 -gstrict-dwarf to restrict GCC to just DWARF2, but epilogue unwind info is emitted unconditionally whenever unwind info is emitted.
So you should see if there is a newer GDB in macports.