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.
In order to make things easier for the Fedora GDB maintainer, we
choose to auto-generate the local patches by making use of an upstream
git repository. Below you can find a few instructions on how to work
using this method.
You need to run the following commands from the directory that
contains the "gdb.spec" file.
Importing the GDB patches into a git repository
The local patches (*.patch) need to be imported into an upstream
git repository. For example, let's assume you cloned the repository
by doing:
TIP: if you already have the repository cloned somewhere in your
system, you can pass a "--reference
" to the "git clone"
command and it will use your local repository as much as possible
to make the clone, speeding up things.
After cloning the upstream repository, you can import your patches
by using the script "generate-git-repo-from-patches.sh":
$ sh generate-git-repo-from-patches.sh <REPOSITORY_DIR>
The script will basically cd into the repository, checkout the
revision specified in the file _git_upstream_commit, iterate through
the file _patch_order and "git-am" every patch in that order.
This operation should complete without errors; if you find a problem
with git-am, it probably means that the revision specified in the
file _git_upstream_commit is wrong.
Rebasing the patches against a newer version/release
First, cd into the upstream repository. All you have to do is
choose the revision against which you plan to rebase the patches, and
git rebase <REVISION>. git will do the rest, and you will be able
to perform conflict resolution by git's algorithm, which is smarter.
Creating new patches
Create the new patch on top of the the others, as usual. Note that
you can use git rebase whenever you want to reorder patch order, or
even to delete a patch.
When writing the commit log, you must obey a few rules. The
subject line must be the filename of the patch. This line will be
used when exporting the patches from the git repository, and
(obviously) it gives the filename that should be used for this
specific patch.
You can also add comments that will go into the auto-generated
Patch: file (see below). To do that, use the special marker ;; at
the beginning of the line. This way, a commit log that says:
test-patch.patch
;; This is a test patch
;; Second line
Will generate the following entry in the auto-generated Patch: file:
# This is a test patch
# Second line
PatchXYZ: test-patch.patch
Exporting the GDB patches from the git repository
When you're done working with the patches, go back to the directory
that contains the gdb.spec file, and from there you run:
$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR>
This will regenerate all of the *.patch files (excluding the ones that
were also excluded from the git repository), and also regenerate a few
control files. These control files are:
_gdb.spec.Patch.include: This file contains the Patch: directives.
_gdb.spec.patch.include: This file contains the %patch directives.
_patch_order: This file contains the patches, in the exact order
that they must be applied. It is used when importing the patches
into the git repository.
_git_upstream_commit: This file contains the last upstream commit
against which the patches were rebased. It is used when importing
the patches into the git repository.
NOTE: If you did a rebase against a newer upstream version, you need
to specify the commit/tag/branch against which you rebased:
$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> <COMMIT_OR_TAG_OR_BRANCH>
For example, if you rebased against gdb-8.1-release:
$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> gdb-8.1-release
