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.
This patch disables the gdb-minimal package on GTS for RHEL9. Since
the -minimal package only exists to shrink the buildroot size and
we don't use GTS in the buildroot, there's no reason to build it.
Defining this option will iimit the tests performed with the "--with testsuite"
option:
$ rpmbuild -bb --with testsuite --define 'tests "gdb.base/break.exp gdb.dwarf2/*.exp"' \
gdb.spec
The above will build the RPM with testing, but it will only test the listed tests
(just as if they were passed to TESTS="gdb.base/break.exp gdb.dwarf2/*.exp").
(This is a workaround for the bogus warning/error that we now see
on i686 regarding a "may write a terminating nul past the end of
the destination" message for the sprintf() call in
global_symbol_searcher::search() in gdb/symtab.c.)
