Errors While Trying to Build Gdb for Arm

Errors while trying to build GDB for ARM

Your command looks correct. The reason it doesn't work as expected must be that your ARM cross-compilation toolchain is not available in your $PATH or its prefix is not arm-linux-gnueabi.

As an example suppose that you downloaded gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabi.tar.xz toolchain and unpacked it under ~/tmp. The following commands should build gdb successfully:

PATH="$PATH:$HOME/tmp/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabi/bin"
./configure --host=arm-linux-gnueabi
make

I shortened ./configure invocation because defaults suffice (TARGET=HOST and BUILD=<automatically guessed>).

The confusion here comes from the fact that --host=... makes configure script look for arm-linux-gnueabi-gcc (...-ld, etc.), but in case it can't find them gcc, ld are used assuming that they cross-compile to HOST. This fallback behaviour is what happened here.

To make sure that correct toolchain is used, watch for

checking for arm-linux-gnueabi-gcc...  found arm-linux-gnueabi-gcc

line in the output of configure.

Do not specify LD=arm-XXX-ld CC=arm-XXX-gcc CXX=arm-XXX-g++ as others have suggested, the point of --host= option is to find these things for you, you just need to put them in your $PATH.

gdb can't cross-compile for arm-linux

./configure --target=arm-none-linux-gnueabi --host=i386-redhat-linux -v

Don't use --target. It means something else to Autotools.

Use --build and --host. Something like:

./configure --build=$(config.guess) --host=arm-none-linux-gnueabi

--build should specify the machine you are running Autotools on, and --host should specify the machine the package will run on.

Note there is some Autootols bug that requires you to specify both --build and --host. It is yet another Autotools problem that has never been fixed.

Also see 2.2.8, Cross-Compilation in the Autools manual.

You will still need to get the paths and sysroot right, but this should provide the proper configure command so things begin to fail as expected.

---

config.guess will return a triplet for the machine you are running Autotools on:

$ find /usr/share/ -name config.guess
/usr/share/libtool/build-aux/config.guess
...

$ /usr/share/libtool/build-aux/config.guess
x86_64-pc-linux-gnu

If you find the package has one but it is out of date you can update it with the following command. You usually need to do this for AIX and Solaris machines.

wget 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess' -O config.guess

And you can update config.sub the same way:

wget 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub' -O config.sub

Error cross-compiling binutils-gdb for windows

This is because you are building the current, non-release,development version - I got the exact same error while building from the latest git revision at the time I cloned the repository, 0a703a4cedffa6f3824e87f115e8d392e32de191.

If you really want to build from the development tree, you will have to wait for the issue to be fixed, or to fix it by yourself - this is not being addressed in this answer.

But if building the latest released version, 2.36.1, is sufficient, the procedure hereafter will work (tested on Ubuntu 20.04 TLS):

wget https://ftp.gnu.org/gnu/binutils/binutils-2.36.1.tar.gz
tar zxf binutils-2.36.1.tar.gz
mkdir binutils
cd binutils
../binutils-2.36.1/configure --prefix=$(pwd)/binutils-2.36.1-x86_64-w64-mingw32 --target=arm-none-eabi --program-prefix=arm-none-eabi- --host=x86_64-w64-mingw32
make
make install
ll -gG binutils-2.36.1-x86_64-w64-mingw32/bin/
total 159144
drwxrwxr-x 2     4096 Apr  7 14:41 ./
drwxrwxr-x 6     4096 Apr  7 14:41 ../
-rwxr-xr-x 1  9212998 Apr  7 14:41 arm-none-eabi-addr2line.exe*
-rwxr-xr-x 2  9748961 Apr  7 14:41 arm-none-eabi-ar.exe*
-rwxr-xr-x 2 14457348 Apr  7 14:41 arm-none-eabi-as.exe*
-rwxr-xr-x 1  9077841 Apr  7 14:41 arm-none-eabi-c++filt.exe*
-rwxr-xr-x 1   816086 Apr  7 14:41 arm-none-eabi-elfedit.exe*
-rwxr-xr-x 1 10783524 Apr  7 14:41 arm-none-eabi-gprof.exe*
-rwxr-xr-x 4 14526998 Apr  7 14:41 arm-none-eabi-ld.bfd.exe*
-rwxr-xr-x 4 14526998 Apr  7 14:41 arm-none-eabi-ld.exe*
-rwxr-xr-x 2  9259673 Apr  7 14:41 arm-none-eabi-nm.exe*
-rwxr-xr-x 2 10655762 Apr  7 14:41 arm-none-eabi-objcopy.exe*
-rwxr-xr-x 2 14908446 Apr  7 14:41 arm-none-eabi-objdump.exe*
-rwxr-xr-x 2  9748961 Apr  7 14:41 arm-none-eabi-ranlib.exe*
-rwxr-xr-x 2  6156460 Apr  7 14:41 arm-none-eabi-readelf.exe*
-rwxr-xr-x 1  9193640 Apr  7 14:41 arm-none-eabi-size.exe*
-rwxr-xr-x 1  9190290 Apr  7 14:41 arm-none-eabi-strings.exe*
-rwxr-xr-x 2 10655762 Apr  7 14:41 arm-none-eabi-strip.exe*

I did not test building from the git repository after having checked-out the binutils-2_36_1 tag:

git -C binutils-gdb checkout binutils-2_36_1

But it should work, if what was tagged is what was packaged in the archive file, which should be the case.

Why is gdb throwing internal errors and telling me that there is a bug?

Can someone tell me what is going on

GDB has already told you:

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

If a program ever reports that it itself has a bug then it is always right. Even if the behavior it thinks is buggy in fact is not, then the program is buggy to say otherwise.

In this particular case, GDB is reporting the failure of an assertion in its own code. This is definitely an implementation bug, not a bug-reporting bug.

why it's happening

It is likely triggered by something unusual about the program being debugged -- which may be buggy itself -- but that doesn't make it any less a GDB bug.

and how to fix it please?

You are unlikely to be able to fix the gdb bug yourself, but it may be that there is a newer version to which you could upgrade, in which the bug has been fixed.

build gdb and gdbserver for android

Got answer from somewhere else, put here in case who wants do the same.

1. Download gdb source code:

   wget ftp://sourceware.org/pub/gdb/releases/gdb-9.1.tar.gz

2. Extract file:

 tar xzvf gdb-9.1.tar.gz

3. Move into source folder

 cd gdb-9.1

4. Edit file gdb/gdbserver/linux-low.c:

• 4.1. Add two lines : Line 107 & Line 122 with the content below

#define HAVE_ELF32_AUXV_T  //  Line 107 (Added)
#ifndef HAVE_ELF32_AUXV_T

#define HAVE_ELF64_AUXV_T // Line 122 (Added)
#ifndef HAVE_ELF64_AUXV_T

This modification is neccessary to build Android, since Android system libraries already define struct Elf32_auxv_t and Elf64_auxv_t .(Please see this for detail: https://github.com/android/ndk/issues/1008)

• 4.2. Modify function linux_request_interrupt:

static void
linux_request_interrupt (void)
 {
   /* .... */
-  kill (-signal_pid, SIGINT); // replace this line with next 3 lines
+  int r = kill (-signal_pid, SIGINT);
+  if (r != 0)
+      kill (signal_pid, SIGINT);
 }

This fixes bug "gdbserver not handling Ctrl+C", detail at: https://sourceware.org/bugzilla/show_bug.cgi?id=18772

5. Build gdb for linux:

sudo apt-get install build-essential \
  gcc g++ make autogen m4 \
  bison gettext libpython-dev

mkdir build-linux

cd build-linux/

../configure --enable-targets=all --with-python=/usr/bin/python

make -j4

sudo make install

6. Build gdbserver for android:

• 6.1. Download android-sdk

cd ~

mkdir android

cd android

wget https://dl.google.com/android/repository/commandlinetools-linux-6200805_latest.zip

unzip commandlinetools-linux-6200805_latest.zip

export PATH=$PATH:~/android/tools/bin

• 6.2. Install Ndk

sdkmanager --install "ndk;21.0.6113669" --sdk_root=.

• 6.3. Create standalone toolchain for NDK

cd ~/android/ndk/21.0.6113669/

./build/tools/make-standalone-toolchain.sh \ 
--toolchain=aarch64-linux-android-4.9 \
--install-dir=~/android/ndk_21

This step create the standalone toolchain at: ~/android/ndk_21

• 6.4. Configure and build gdbserver for android

cd ~/gdb-9.1

mkdir build-android

cd build-android

export PATH=$PATH:~/android/ndk_21/bin

CC=aarch64-linux-android-gcc ../configure \
    --target=aarch64-linux-android \
    --host=aarch64-linux-android \
     LDFLAGS="-static-libstdc++"

make -j4

If get error related to "source-highlight", add --disable-source-highlight to the configure flag.

After build finishes, gdbserver is located at: gdb/gdbserver/gdbserver

---

Related Topics