cmake: gnu: Fix debugging when GDB fails to load because of Python

[carlescufi]

GDB can be built with or without Python support. When built with Python
support this can cause a particular problem: The gdb executable relies
on shared libraries that are bound to a specific Python version. But
since most Linux distributions typically ship with a single version, it
is very difficult to choose which one to target when building GDB.
When GDB executes, if it fails to load the shared libraries it will exit
immediately with an error code of 127 and output resembling this:

/home/carles/bin/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb:
error while loading shared libraries: libpython3.8.so.1.0: cannot open
shared object file: No such file or directory

There are two known approaches to shipping multiple gdb executables:

• The Zephyr SDK ships a default gdb with Python enabled, and then a
  separate gdb-no-py executable with Python disabled
• GNU Arm Embedded ships with a default gdb with Python disabled, and an
  additional gdb-py with Python enabled

To mitigate the problem of not being able to debug, fall back to a
'gdb-no-py' if it exists whenever the standard gdb executable fails to
even run.

Signed-off-by: Carles Cufi carles.cufi@nordicsemi.no

[carlescufi]

CC @sylvainpelissier

[carlescufi]

Note: I plan to extend this with support with both -py and -no-py in west itself as well, but post-2.7.0.

[stephanosio]

This looks reasonable and will be very useful for the users who do not have the "correct" version of Python installed.

In the future, this issue can be further mitigated by allowing users to select which gdb to use through the west as @carlescufi noted. Also, we can look into making the default gdb provided by the Zephyr SDK Python-less as the GNU Arm Embedded toolchain does, since most users do not require the Python scripting capability.