December 9, 2022

Gdb for ARM on Fedora

The answer was to locate and install the old Fedora 24 RPM, as described at the end of this page.

About 10 years ago (in Fedora 24) there was a Fedora package that provided this, but that package got dropped when the maintainer lost interest and nobody has picked it up. I have been tempted to, but I don't use gdb often enough to get excited about it.
Back in those days, this package was available:

ARM offers the latest gdb as part of the ARM toolchain they have for download

This didn't work and was a waste of time, but the details follow, with some things regarding libraries that may be helpful. When it was said and done, I deleted the whole mess, thumbed my nose, and went on to other things. I go for the latest download for x86_64 linux host (and a bare metal target). This is from the official ARM developer site, so I feel confident using this link. It is a big download (564M) and takes a few minutes.
This gives me: 
arm-gnu-toolchain-12.2.mpacbti-bet1-x86_64-arm-none-eabi.tar.xz
unxz arm-gnu-toolchain-12.2.mpacbti-bet1-x86_64-arm-none-eabi.tar.xz
tar xvf arm-gnu-toolchain-12.2.mpacbti-bet1-x86_64-arm-none-eabi.tar
ln -s arm-gnu-toolchain-12.2.mpacbti-bet1-x86_64-arm-none-eabi toolchain
cd toolchain
cd bin
su
cp arm-none-eabi-gdb /usr/local/bin
But there are missing libraries: 
./arm-none-eabi-gdb
./arm-none-eabi-gdb: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory
This is the same error that the fellow in the Reddit thread describes.
My system has this: 
/usr/lib/libncurses.so.6
/usr/lib/libncurses.so.6.3
There is no telling why the guys at ARM are building against an old libncurses. I have a variety of libncurses.so.5 files kicking around from old backups. (Even in Fedora 24 days libncurses was on to "6"). Rather than just copy one of those into /usr/lib (and/or /usr/lib64) I use the tip from the Reddit discussion and do: 
dnf install ncurses-compat-libs
There is no such package (under Fedora 37), but that only makes sense. So I do this on my system: 
locate libncurses.so.5
/u1/f24_root/usr/lib64/libncurses.so.5
/u1/f24_root/usr/lib64/libncurses.so.5.9
So, by sheer luck I have an appropriate old version of libncurses in an old backup, so ... 
su
cd /u1/f24_root/usr/lib64
cp libncurses.so.5.9 /usr/lib64
cp libncursesw.so.5.9 /usr/lib64
cp libtinfo.so.5.9 /usr/lib64

cd /usr/lib64
ln -s libncurses.so.5.9 libncurses.so.5
ln -s libncursesw.so.5.9 libncursesw.so.5
ln -s libtinfo.so.5.9 libtinfo.so.5

Python Hell

It launches now, but with a number of Python errors (how did Python get tangled up with gdb?) 
Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = '/usr/local/bld-tools/bld-tools-virtual-env/bin/python'
  ......
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'
Of course the path with /usr/local/bld-tools does not exist on my system.

At this point I call this hopeless. First of all, why python is gdb using? Python2 or Python3, and why? I fire up both python 2 and python3 on my system and do this: 

import os
print ( os.environ )
And there ain't no PYTHONPATH set. I would probably be better off getting the gdb sources and trying to build it myself. At least I would know then what this python business is all about.

Sources

During my search for the release notes, I ran across a link to this:

Release Notes

Where the heck are they? Various places on the ARM site tells you to go get them, but it seems to be some kind of game to track them down. They say to look in share/doc/arm-none-eabi/readme.txt, but there is nothing useful there. There is a vast amount of stuff in share/doc (as html files). What looks interesing is the directory "gccinstall". I do battle with my browser and manage to get it to view: 
file:/u1/ARM-toolchain/toolchain/share/doc/gccinstall/index.html
It is standard Gnu project information about installing gcc

The release notes say nothing about how to install it (other than to unpack it to the "desired installation directory", but do mention that Python 3.8 is required to use gdb. The Fedora 37 I am using has Python 3.11.0. They say that only linux systems get the broken Python stuff, on Windows or Mac you have to do without it. (ha ha). They say the Linux versions are built for RHEL7.

"GDB's Python support on Linux hosts requires installation of Python3.8, Python3.8-dev or libpython3.8."

Try what they say (doesn't work)

su
cd /opt
ln -s /u1/ARM-toolchain/toolchain .
After this, I can try invoking gdb via: 
/opt/toolchain/bin/arm-none-eabi-gdb
This fixes nothing. I still get the same crazy python errors. I had hoped that by invoking it with a full path it might have inspected the invoked path to find other parts of the install tree, but no such luck.

Forget the stuff from ARM, use the old Fedora 24 file

Look at this: 
locate arm-none-eabi-gdb
/u1/f24_root/usr/bin/arm-none-eabi-gdb
I find other copies as well (one in the Xilinx SDK from 2019.1, but what the heck let's try this old executable. 
su
cd /u1/f24_root/usr/bin
cp arm-none-eabi-gdb /usr/local/bin
Now I get this: 
[tom@trona bin]$ which arm-none-eabi-gdb
/usr/local/bin/arm-none-eabi-gdb
[tom@trona bin]$ arm-none-eabi-gdb
Python Exception  No module named gdb:

warning:
Could not load the Python gdb module from `/usr/share/gdb-arm-none-eabi-7.6.2/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

GNU gdb (GDB) 7.6.2
Copyright (C) 2013 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 "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
.
(gdb)
Well, that is more like it. And it gives me the hint of looking in /usr/share for the python rubbish, whatever it is. And by golly, there it is in my old Fedora 24 backup, namely the directory gdb-arm-none-eabi-7.6.2.

Can we just find the F24 RPM

We can, and here it is if you want and need it: Note that this "just worked" for me, but I installed ancient libraries and other stuff during all the trashing around described above. So if you encounter problems, read the rubbish above this. Allegedly this was in "the list" through Fedora 29.
After some searching I found these files: 
arm-none-eabi-gdb-7.6.2-4.fc24.x86_64.rpm
arm-none-eabi-gdb-7.6.2-4.fc24.src.rpm
arm-none-eabi-gdb-devel-7.6.2-4.fc24.x86_64.rpm
So, I just do: 
dnf install arm-none-eabi-gdb-7.6.2-4.fc24.x86_64.rpm
Bam!! Voila!! It works. 
[tom@trona tom]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 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 "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
.
(gdb)
Looks good.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org