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.
The use of "%patchNNN" to apply patches is deprecated. "%patch -PNNN"
is recommended for maximum compatibility with older versions of `rpm'.
Regenerated all patches and associated files.
Instead of placing the distro name (e.g. 'Fedora Linux') into the
version.in file, use the --with-pkgconfig configure option to set the
disto name.
This does change GDB's version output slightly. Prior to this commit
we might expect to see something like this:
$ gdb --version
GNU gdb (GDB) Fedora Linux 13.1-1-fc38
...
Now we'll see this:
$ gdb --version
GNU gdb (Fedora Linux) 13.1-1-fc38
...
Notice that 'Fedora Linux' moved inside the parenthesis.
There are other benefits to this change, the Python gdb.VERSION
string will now contain '13.1-1-fc38' instead of 'Fedora Linux
13.1-1-fc38', this was reported as an issue in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2179554
I've also removed the change to gdb.gdb/selftest.exp as I don't
believe that this was ever being used -- when this test was run we
should have hit an earlier case.
I have added a brand new test that checks our version string. I've
placed this new test into a separate file, so we should (hopefully)
not have any issues maintaining this as an out of tree test.
For implementation, by default we make use of the %dist_name macro,
however, this is not defined on RHEL 9 or earlier, so to support
reusing this commit on RHEL systems, I also detect the %rhel macro,
and in that case use a hard-coded string.
Update gdb-6.3-rh-testversion-20041202.patch.
Update gdb-6.3-bz140532-ppc-unwinding-test.patch.
Update gdb-6.6-buildid-locate.patch.
Update gdb-6.6-buildid-locate-rpm.patch.
Remove 'Recommends: ' line for gcc-gdb-plugin for BZ2149246.
Add 'define _lto_cflags ' to avoid ODR violations.
Add -Wno-stringop-overflow to --enable-gdb-build-warnings to work around
gcc problem.
The patch 'gdb-test-ivy-bridge.patch' adds some disassembly tests for
various i386/x86-64 instructions. In fact, the tests added by this
patch are copied directly from gas and should all be covered by
gas/testsuite/gas/i386/i386.exp.
I guess historically, when support for these instructions was first
added, it made sense to have these tests in both GDB and binutils.
But today I think that the testing in binutils is sufficient; if we
really want to validate libopcodes we'd be better off building and
testing gas/binutils as well as GDB.
I propose that we just drop 'gdb-test-ivy-bridge.patch' from the
Fedora GDB tree.
Remove gdb-6.5-readline-long-line-crash-test.patch, this test is now
upstream in commit:
commit bb146a79c7d65e2b578e8c3f652cb118c63741e5
Date: Thu Feb 9 10:52:47 2023 +0000
gdb: add test for readline handling very long commands
As this is only a test, I don't see any point in backporting the
upstream commit, we'll pick this up with a later rebase.
Following on from the previous commit, this commit remove
gdb-6.8-bz442765-threaded-exec-test.patch.
Like the previous commit, this patch was a testsuite only patch that
extended the test originally added in the previous commit, in order to
do some additional threads/exec related testing.
The issue exposed by this test (Bug bz442765) was present on Fedora 9,
with GDB 6.8-1.fc9. I have setup a Fedora 9 VM and recreated the
failure with the test in the patch I'm deleting here.
The test does a number of exec's, in each iteration the test binary
runs in a different mode. However, the failure is triggered when we
have a main thread that spawns a worker thread and then called exec
from the main thread.
Just like the previous commit, this situation already exists in the
upstream test gdb.threads/execl.exp, and, if I copy this upstream test
to my Fedora 9 VM, I can reproduce the failure using this upstream
test.
The test being deleted here does do a number of other permutations of
threading and execing, for example it tests calling exec in a
non-threaded inferior, but this is also tested upstream with things
like gdb.base/foll-exec.exp.
In summary, I don't believe there is anything new added by this test
that is not already covered with existing upstream tests, as such, I
think we should drop this patch.
Remove gdb-6.3-bz202689-exec-from-pthread-test.patch. The test
included in this patch is covered by the already upstream test
gdb/testsuite/gdb.threads/execl.exp which was added with this commit:
commit 49fd4a422bb6152043b2b41a1f734694056dbf3b
Date: Thu Jun 5 21:03:59 2008 +0000
Unfortunately, the situation is not as simple as just removing this
patch file. The later patch gdb-6.8-bz442765-threaded-exec-test.patch
builds on the earlier test to cover additional cases.
So, what I've actually done is remove the first patch, but merged the
test entirely into the second patch. I think this is a better
reflection of the current situation; the first patch is
redundant (it's test is already covered upstream), while the second
patch has not yet been reviewed, so it _might_ contain a useful test.
To confirm that the upstream test quoted above actually covers this
test case I did the following:
- Setup a Fedora 3 virtual machine,
- Built the test from the first patch and confirmed that it failed
as described in bug bz202689,
- Copied the upstream execl.exp sources to the virtual machine, and
built the test binary,
- Manually ran the test binary just as the .exp script does, and
confirmed that it failed in the same way as the test from the
original patch.
Remove gdb-6.6-bz230000-power6-disassembly-test.patch as this is now
covered by upstream tests. This patch added some tests of the Power6
disassembler. Disassembler tests are better carried in the gas tree.
Upstream commit:
commit 0fcf99b8ab5ccbde30fa7d36742e670cd4df48ef
Date: Mon Jan 30 11:47:31 2023 +0000
gas/ppc: Additional tests for DFP instructions
Added some new assembler/disassembler tests to the gas tree that
covered all the instructions that were covered by our local patch.
...so that $_gdb_major and $_gdb_minor will be obtained correctly.
Also, change define of 'use_guile' from empty (which rpmbuild
complained about) to a value of 1. I encountered this problem
while attempting to build on F37.
This upstream commit:
commit 24f3aded1d42f515527e2de7e8e9e26f0b77c932
Date: Tue Dec 20 15:01:29 2022 +0000
gdb/testsuite/tui: more testing of the 'focus' command
replaces the tests added in gdb-6.3-focus-cmd-prev-test.patch. As
this patch was only adding a test I see no need to back-port the
upstream commit, we'll pick this up in a later rebase.
- Backport fix for problems associated with GCC 13's self-move warning.
- Tweak gdb-6.6-buildid-locate-rpm.patch so that running GDB's configure
script will not error out due to GCC 13's warnings.
- Backport replace deprecated distutils.sysconfig in python-config.
Fixes RHBZ 2152431, an issue where reading a label symbol's value
would cause GDB to crash. This pulls in two upstream commits
38665d717a3 and c3efaf0afd9 both of which should be in GDB 13 when it
is released.
Changes in this commit:
- Remove gdb-bz601887-dwarf4-rh-test.patch
This adds a very simple test to check whether DWARF4
is implemented. GDB has been using DWARF4 for several
years, and the testsuite coverage supercedes this patch.
- Remove gdb-6.6-buildid-locate-rpm-scl.patch
This patch is applicable only on RHEL6 where .gdb_index
version 5 is used. In recent GDBs, i.e., all DTS releases,
this version could only be read with the option
"use-deprecated-index-sections". RHEL7+ use .gdb_index version 8.
Since RHEL6 is no longer supported, this is unnecessary.
Also remove GDB_INDEX_VERIFY_VENDOR references/code from
gdb-6.6-buildid-locate.patch and gdb.spec
Remove the 'gdb-fortran-frame-string.patch' patch from Fedora GDB. I
have pushed an upstream test that covers everything that this test
covered, see upstream GDB commit:
commit 1c01b23603766fbca4ed4dd12fdd710860e6038e
Date: Fri Nov 4 14:51:11 2022 +0000
gdb/fortran/testsuite: print values and types of string variables
As this is just a testsuite patch, I'm not going to backport this to
Fedora GDB, but when we next rebase, we will pick up this test.
The patch 'gdb-bfd-aliasing.patch' is no longer applied as part of the
Fedora GDB build, since this commit to the Fedora GDB repository:
commit c0cbb1aae4
Date: Sat Mar 19 21:26:41 2016 +0100
.spec cleanup: Drop strict-aliasing GCC bug workaround (from RH BZ 1315191).
I propose that we remove this file from the repository.
The three patches:
gdb-entryval-crash-1of3.patch
gdb-entryval-crash-2of3.patch
gdb-entryval-crash-3of3.patch
are not being applied to the Fedora build of GDB, since this commit to
the Fedora GDB repository:
commit 902c8e5abc
Date: Thu Jul 24 20:04:47 2014 +0200
Rebase to FSF GDB 7.7.91.20140724 (pre-7.8 snapshot).
The contents of the first two were reverting an upstream commit,
which, based on the dialog in the patch files, was done to mask a bug
in a different part of GDB, which I assume is now fixed.
The third patch adds a couple of tests, which are now all upstream,
and passing, I assume these tests covered the issue that was causing
the problem with the first two patches.
Given these patches are not being applied, and the relevant work seems
to be in upstream GDB, I propose we drop these three files from the
repository.
- gdb-physname-pr11734-test.patch
- gdb-physname-pr12273-test.patch
These two tests were merged upstream under a different file name.
- gdb-runtest-pie-override.patch
This patch appears unnecessary today. I have tested on all supported
host architectures and detected no regressions. I presume this was
fixed in a different manner through the years.
- gdb-test-expr-cumulative-archer.patch
The patch contains two tests. Both are upstream already.
While one is a little more involved than what landed upstream,
both tests are equivalent. The other test, gdb.cp/namespace-no-imports.exp,
is identical to upstream's gdb.cp/nsnoimports.exp with whitespace
and other trivial changes.
The test added by this patch from 2005 is a tweaked verion of the upstream
test gdb.threads/watchthreads.exp from 2004. (The current version of
gdb.threads/watchthreads.exp has changed somewhat since 2004.)
The tweaks added to the circa 2004 upstream test consist of setting
a breakpoint on thread_function and then continuing to it. At
that point, initial / runtime values of args[2] and args[3] are
fetched and saved in some TCL variables (which are renamed versions
of args_0 and args_1 in watchthreads.exp). The rest of the changes
to the tweaked script are mostly related to the renaming related to
args_0 and args_1. The other major difference is that watchthreads.exp
places hardware watchpoints on args[0] and args[1] whereas the
tweaked test instead watches args[2] and args[3]. However, all
of these initialized to 0. In the tweaked test, fetching the
initial values when the thread function is first hit should result
in zero values being fetched for args[2] and args[3].
So, in conclusion, the tweaked version of the test doesn't actually
test anything new. I took a look at old posts / threads from the
gdb-patches mailing list, but I couldn't find a post where Jeff
Johnston included this patch (and an explanation of what it does over
the other patch.)
Since this test doesn't offer anything new/better over what's already
upstream, I'm deleting it.
In my .gitconfig I have this:
[format]
useAutoBase = true
thread = shallow
As a consequence, when I run generate-patches-from-git-repo.sh I see
two problems, first, I see lots of errors like this:
fatal: failed to get upstream, if you want to record base commit automatically,
please use git branch --set-upstream-to to track a remote branch.
Or you could specify base commit by --base=<base-commit-id> manually
These are caused by the use of the useAutoBase option.
If I disable useAutoBase, and regenerate the patches, I see that every
patch changes, with the addition of a line like this:
Message-Id: <some message id string here...>
This is caused by the use of the thread option.
Rather than forcing me to not have these settings in my .gitconfig, I
propose that we add --no-base and --no-thread to our invocation of
'git format-patch' in generate-patches-from-git-repo.sh, this fixes
both of the above problems.
With these new options the 'git format-patch' line was getting pretty
long, so I've wrapped it to make it more readable.
