SOLUTION FOUND - support remote debug from x86_64 based PC gdb client with gdbgui, to ARM arch gdbserver (multiarch)

TLDR - I found a way to make gdbgui work for my usecase described! I'll put the fix at the bottom of the post

**Is your feature request related to a problem? Please describe.**
I really want to be able to use gdbgui frontend for a multiarch remote debugging usecase. My target system is running gdbserver on an ARM based device. If I try to run `gdbgui` then connect to gdbserver by any means (`target remote 192.168.0.212:9091`) I get the following issue:

```
target remote 192.168.0.212:9091

Remote debugging using 192.168.0.212:9091

warning: Architecture rejected target-supplied description

Reading /home/root/myRemoteTestApplicationExecutable from remote target...

warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.

Architecture of file not recognized.
```
So I believe this issue is that my desktop machine's `gdb` binary is not sufficient for multiarch debugging, so I did:
`sudo apt-get install gdb-multiarch` on my Ubuntu system. I tried it out just with commandline first, and it works like a charm:
`gdb-multiarch --eval-command="target remote 192.168.0.212:9091"`

Now though, I want to use gdb-multiarch as the debugger binary for gdbgui
`gdbgui --gdb gdb-multiarch --gdb-args='--eval-command="target remote 192.168.0.212:9091"'`
OR
`gdbgui --gdb gdb-multiarch`
* then use GUI to connect to gdbserver...

This method sadly also doesn't work, giving me a different error though:
```
gdbgui spawned subprocess with pid 28321 from executable gdb-multiarch.

gdb process 28321 is running for this tab

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
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.

.... editing out some boilerplate GDB output...

set breakpoint pending on

warning: Architecture rejected target-supplied description

Reading /home/root/myRemoteTestApplicationExecutable from remote target...

warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.

Reading /home/root/myRemoteTestApplicationExecutable from remote target...

Reading symbols from target:/home/root/myRemoteTestApplicationExecutable...

done.

Reading /lib/ld-linux-armhf.so.3 from remote target...

Reading /lib/ld-linux-armhf.so.3 from remote target...

Reading /lib/ld-2.23.so from remote target...

Reading /lib/.debug/ld-2.23.so from remote target...

0x76fcfac0 in ?? () from target:/lib/ld-linux-armhf.so.3

Connected to remote target! Adding breakpoint to main, then continuing target execution.

Program

received signal SIGSEGV, Segmentation fault.

0x00000000 in ?? ()

gdbgui noticed a signal was recieved (Segmentation fault, SIGSEGV).

If the program exited due to a fault, you can attempt to re-enter the state of the program when the fault

occurred by clicking the below button.

Program

received signal SIGSEGV, Segmentation fault.

0x00000000 in ?? ()

gdbgui noticed a signal was recieved (Segmentation fault, SIGSEGV).

If the program exited due to a fault, you can attempt to re-enter the state of the program when the fault

occurred by clicking the below button.

Program terminated with signal

SIGSEGV, Segmentation fault.

The program no longer exists.

/home/root/myRemoteTestApplicationExecutable: No such file or directory.

Cannot access memory at address 0x0
```

**Describe the solution you'd like**
I am not picky, but so long as there's a way to use `gdbgui` to debug a remote gdbserver that's actually running ARM arch instead of matching the desktop architecture would be an absolute dream! (I'd even take a solution from any similar tool to gdbgui, but this one is really quite nice).

**Describe alternatives you've considered**
The closest I've gotten (aside from just using `gdb-multiarch` commandline) is using `ddd` but it's ancient and buggy on my modern system.
`ddd --eval-command="target remote $ADOLOCAL:9091" --debugger gdb-multiarch`
This gives some sort of minimal GUI and I've been able to set breakpoints and step through (so it gets further than gdbgui at the moment) -- but it's really clunky, and freezes up constantly.

**Additional context**

TLDR Solution:

I was trying to rely on a prebuild gdb-multiarch from ubuntu apt repos, which didn't work. When I decided to download gdb and rebuild from source while configuring for arm-linux-gnuabi target arch.

Build method:

1. downloaded latest gdb source code
2. unzip it, go into folder
3.
```
./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=arm-linux-gnuabi &&
make -j8 &&
sudo make install
```
4. now `arm-linux-gnuabi-gdb` is installed by default to /usr/local/bin ... but you can instead provide `prefix=` to where you want it to install in `./configure` script above

Using this, I was able to build a secondary copy of gdb called `arm-linux-gnuabi-gdb` which i could feed to gdbgui like this:

`gdbgui -g arm-linux-gnuabi-gdb`

Works great! This is leaps and bounds better than running gdb on commandline on my remote target.

Relevant link for building gdb:
https://sourceware.org/gdb/wiki/BuildingCrossGDBandGDBserver
http://www.brain-dump.org/blog/entry/138/Cross_Arch_Remote_Debugging_with_gdb_and_gdbserver

The report names the gdbgui CLI and its --gdb option, but no repository files or tests. First verify whether the request is still relevant; if pursued, define and test support for an ARM-target GDB executable connecting to gdbserver, since the author reports success with arm-linux-gnuabi-gdb.

Written by the indexing model from the issue text.