Update local patches:
gdb-6.5-bz185337-resolve-tls-without-debuginfo-v2.patch
gdb-6.6-buildid-locate-rpm.patch
gdb-6.6-buildid-locate.patch
gdb-container-rh-pkg.patch
gdb-core-open-vdso-warning.patch
gdb-fedora-libncursesw.patch
gdb-linux_perf-bundle.patch
Update backported patches which didn't make it into 14.1:
gdb-rhbz-2232086-cpp-ify-mapped-symtab.patch
gdb-rhbz-2232086-generate-gdb-index-consistently.patch
Drop upstreamed local patches:
gdb-6.5-sharedlibrary-path.patch
Drop gdb-13.2 backports (which are now in gdb-14.1):
gdb-binutils29988-read_indexed_address.patch
gdb-bz2196395-debuginfod-legacy-openssl-crash.patch
gdb-bz2237392-dwarf-obstack-allocation.patch
gdb-bz2237515-debuginfod-double-free.patch
gdb-rhbz2192105-ftbs-dangling-pointer
gdb-rhbz2233961-CVE-2022-4806.patch
gdb-rhbz2233965-memory-leak.patch
Adjust gdb.spec so that --with-mpfr is no longer passed to
configure; doing so, combined with some configury changes triggered
a latent build problem.
Backport upstream commits 1f0fab7ff86, aa19bc1d259, acc117b57f7,
aff250145af, and 3644f41dc80. These commits reduce the size of the
generated gdb-index file, and also ensure that the gdb-index and
dwarf-5 index are generated consistently even as the number of worker
threads that GDB uses changes (RHBZ 2232086).
The first and third of these patches are refactoring, but are required
by the other patches in this series.
The second patch fixes a bug that causes the gdb-index files to
be (sometimes) bigger than needed.
The fourth and fifth patches ensure that the gdb-index and dwarf-5
index (respectively) are generated the same (for the same input
binary), regardless of how many worker threads that GDB uses.
This patch adds an s390x/arch12 binary file to disassemble, checking
for the appearance of two arch12 insns. Remove this patch in favor
of binutil's version, which is much more complete with much more
coverage.
That patch only changed gdb.base/fileio.{c|exp} tests, supposedly to
make them work better when running the test as root. However, that test
only increased the number of fails by 20
The patch gdb-test-pid0-core.patch only contains a test. A similar
test has been merged upstream in commit 8bcead69665, so I propose that
we drop this patch from Fedora, the test will be picked up next time
we rebase.
Every invocation of gdb-add-index will print which possible
gdb command will be used. This is because the which command
always prints the name of the command found. Redirect both
stdout and stderr to /dev/null to suppress this when the
output isn't needed.
An equivalent test has been merged upstream in this commit:
commit ef56b006501ba52b128d4e5f36657ddbf56d22bc
Date: Wed May 17 15:14:15 2023 +0100
gdb/testsuite: test for a function with no line table
As this is only a test there seems little point in backporting this
commit to Fedora -- we'll pick it up next time we rebase. For now I
suggest that we drop this patch.
This patch adds a work around for an issue with older versions of
ccache -- the line number for macros defined at the compiler command
line was '1' instead of '0'.
Not only is this ccache issue fixed with newer versions of ccache, but
upstream GDB now disables ccache during testing, see commit:
commit 49b4de64242d4ae035e0e2197837278e33c187fc
Date: Thu Sep 15 14:04:20 2016 +0200
testsuite: Disable ccache
As a result this work around is no longer needed, and this patch can
be dropped.
The test added by this patch claims to be a power7 test, however, it
actually appears to test instructions from power7, power8, and power9.
All the instructions tested by this patch are already tested by
upstream tests:
gdb.arch/powerpc-power7.exp
gdb.arch/powerpc-power8.exp
gdb.arch/powerpc-power9.exp
As such this patch is redundant and can be removed.
These changes, originally added to Fedora GDB by Keith Seitz, and
described in the Nov 30 2022 Changelog eentry, were inadvertently lost
during the GDB 13.1 rebase. Only downstream/local changes were lost -
the remainder of the changes were in the upstream GDB 13.1 sources.
It has been observed that the changes added by
gdb-libexec-add-index.patch will result in GDB testing hanging when
the tests are being run using an in-tree GDB; that is when using 'make
check'. One test that is known to fail is gdb.base/with-mf.exp,
though any test that calls the gdb-add-index.sh script will also hang.
The problem is that when the gdb-add-index.sh script is run, the GDB
testsuite passes the GDB command to use within the GDB environment
variable. For in-tree testing this will be something like:
GDB="/path/to/gdb -data-directory /path/to/data-directory"
Notice that the environment variable contains both an executable and
an argument.
Our changes to gdb-add-index.sh add this:
GDB2=/usr/libexec/gdb
if test -x $GDB2 && ! which $GDB &>/dev/null; then
GDB=$GDB2
fi
The problem then is that '-data-directory' is treated as a set of
options to 'which'. Many of these options are not known to 'which',
but the '-i' option is known. The documentation of '-i' says:
--read-alias, -i
Read aliases from stdin, reporting matching ones on
stdout. This is useful in combination with using an alias for
which itself. For example
alias which=´alias | which -i´.
And here's the problem; this option causes 'which' to read from
stdin. As the GDB testsuite doesn't send any additional input on
stdin then the which command will never complete, and the test will
hang.
The solution I think is to avoid calling 'which' like this on a user
supplied GDB environment variable.
The changes in the gdb-libexec-add-index.patch were really about what
the _default_ GDB executable should be. The upstream version of this
script does this:
GDB=${GDB:=gdb}
That is, the default is just 'gdb'. However, for RH this is not good
enough. We want to handle two additional cases, first, when only the
gdb-minimal package is installed, in which case the default should be
/usr/bin/gdb.minimal. Then we also want to handle the case where the
user doesn't have 'gdb' itself in their $PATH, but does have the 'gdb'
executable installed in /usr/libexec/gdb.
The code as it currently stands also has a problem where, if
gdb.minimal is installed on the machine this will _always_ be used in
preference to the user supplied GDB value (assuming the code worked at
all) this means that when doing in-tree testing we wouldn't actually
be using the in-tree GDB to build the index, which isn't ideal.
So in this commit I propose that we rework our gdb-add-index.sh
changes. Now, we only use the RH special values in the case that
there is no GDB environment variable set. I believe this handles all
the required use cases:
1. When doing in-tree testing GDB environment variable will be set,
and this will always be used as is, with no special processing,
2. When gdb-add-index.sh is used and GDB environment variable is not
set then we will use the first of the following as the default:
(a) /usr/bin/gdb.minimal if this file exists and is executable,
(b) The first gdb executable that can be found in the $PATH,
(c) /usr/libexec/gdb if this file exists and is executable.
While I was changing this patch anyway I've removed the libexec part
of the patch name -- this no longer seemed relevant, I suspect this
related to an older version of this patch.
Remove gdb-opcodes-clflushopt-test.patch. This patch tests that GDB
can disassemble the clflushopt instruction correctly. Such
disassembly is a feature of libopcode and is covered by the gas
tests i386/x86-64-clflushopt.s and i386/clflushopt.s. Lets remove
this test from GDB and just rely on the gas tests instead.
This patch originally contained some changes to GDB which were
rejected by upstream maintainers. All that remained was a testcase
which had a number of failures due to the rest of the work not being
present in GDB.
This patch exercised an edge case for 32-bit systems in
target_xfer_memory, a function that has been removed in 2006.
The test that patch added has been irrelevant for some time.
