gdb/_gdb.spec.Patch.include

200 lines
6.8 KiB
Plaintext
Raw Normal View History

# Check distro name is included in the version output.
Patch001: gdb-6.3-rh-testversion-20041202.patch
# Add a wrapper script to GDB that implements pstack using the
# --readnever option.
#=push
Rebase to FSF GDB 10.2. Drop gdb-6.3-test-pie-20050107.patch. Drop gdb-6.3-test-self-20050110.patch. Drop gdb-6.5-bz218379-ppc-solib-trampoline-test.patch. Drop gdb-6.6-buildid-locate-core-as-arg.patch. Drop gdb-6.8-quit-never-aborts.patch. Drop gdb-archer-pie-addons-keep-disabled.patch. Drop gdb-archer-pie-addons.patch. Drop gdb-archer-vla-tests.patch. Drop gdb-archer.patch. Drop gdb-attach-fail-reasons-5of5.patch. Drop gdb-btrobust.patch. Drop gdb-bz1219747-attach-kills.patch. Drop gdb-bz533176-fortran-omp-step.patch. Drop gdb-dts-rhel6-python-compat.patch. Drop gdb-gnat-dwarf-crash-3of3.patch. Drop gdb-jit-reader-multilib.patch. Drop gdb-moribund-utrace-workaround.patch. Drop gdb-rhbz1930528-fix-gnulib-build-error.patch. Drop gdb-rhbz1932645-aarch64-ptrace-header-order.patch. Drop gdb-vla-intel-fix-print-char-array.patch. Drop gdb-vla-intel-fortran-strides.patch. Drop gdb-vla-intel-stringbt-fix.patch. Drop gdb-vla-intel-tests.patch. Drop process_psymtab_comp_unit-type-unit.patch. Drop gdb-testsuite-readline63-sigint-revert.patch. Drop gdb-config.patch. Add following upstream patches for Fortran stride / slice support: gdb-rhbz1964167-convert-enum-range_type.patch gdb-rhbz1964167-fortran-array-slices-at-prompt.patch gdb-rhbz1964167-fortran-array-strides-in-expressions.patch gdb-rhbz1964167-fortran-clean-up-array-expression-evaluation.patch gdb-rhbz1964167-fortran-range_type-to-range_flag.patch gdb-rhbz1964167-fortran-whitespace_array.patch gdb-rhbz1964167-move-fortran-expr-handling.patch
2021-06-06 21:54:47 +00:00
Patch002: gdb-6.3-gstack-20050411.patch
# Test sideeffects of skipping ppc .so libs trampolines (BZ 218379).
#=fedoratest
Patch003: gdb-6.5-bz218379-ppc-solib-trampoline-test.patch
# Allow running `/usr/bin/gcore' with provided but inaccessible tty (BZ 229517).
#=fedoratest
Patch004: gdb-6.6-bz229517-gcore-without-terminal.patch
# Avoid too long timeouts on failing cases of "annota1.exp annota3.exp".
#=fedoratest
Patch005: gdb-6.6-testsuite-timeouts.patch
# Support for stepping over PPC atomic instruction sequences (BZ 237572).
#=fedoratest
Patch006: gdb-6.6-bz237572-ppc-atomic-sequence-test.patch
# Test leftover zombie process (BZ 243845).
#=fedoratest
Patch007: gdb-6.5-bz243845-stale-testing-zombie-test.patch
# New locating of the matching binaries from the pure core file (build-id).
#=push+jan
Patch008: gdb-6.6-buildid-locate.patch
# Fix loading of core files without build-ids but with build-ids in executables.
# Load strictly build-id-checked core files only if no executable is specified
# (Jan Kratochvil, RH BZ 1339862).
#=push+jan
Patch009: gdb-6.6-buildid-locate-solib-missing-ids.patch
# Test PPC hiding of call-volatile parameter register.
#=fedoratest
Patch010: gdb-6.7-ppc-clobbered-registers-O2-test.patch
# Test gcore memory and time requirements for large inferiors.
#=fedoratest
Patch011: gdb-6.5-gcore-buffer-limit-test.patch
# Test GCORE for shmid 0 shared memory mappings.
#=fedoratest: But it is broken anyway, sometimes the case being tested is not reproducible.
Patch012: gdb-6.3-mapping-zero-inode-test.patch
# Test a crash on libraries missing the .text section.
#=fedoratest
Patch013: gdb-6.5-section-num-fixup-test.patch
# Fix resolving of variables at locations lists in prelinked libs (BZ 466901).
#=fedoratest
Patch014: gdb-6.8-bz466901-backtrace-full-prelinked.patch
# New test for step-resume breakpoint placed in multiple threads at once.
#=fedoratest
Patch015: gdb-simultaneous-step-resume-breakpoint-test.patch
# Fix follow-exec for C++ programs (bugreported by Martin Stransky).
#=fedoratest
Remove gdb-core-open-vdso-warning.patch The tests added by this patch are similar to those of upstream test gdb.base/vdso-warning.exp. I think that the upstream patch provides better coverage in that it also provides tests involving core files. This patch started out as a change to gdb in Jan 2010 changing gdb/solib-svr4.c. There were no tests included in this initial commit. Tests were added in a commit from June 19, 2012, changing files gdb.base/solib-symbol.exp and gdb.base/corefile.exp. There were also changes made to gdb/solib.c. Tweaks to the test cases were made in commits from July 3, 2012, July 6, 2012, and Jan 19, 2013. Many, maybe all, of the solib-svr4.c and solib.c changes were removed in a commit from Feb 7, 2014. The gdb.base/corefile.exp changes were removed at the same time. There is no explanation in the log for why this was done. However, after reading some gdb-patches discussion from that period, it appears that Jan believed that the correct fix was in glibc and that having a workaround in gdb weakened the argument for what he believed to be a proper fix in glibc. Roland McGrath and Ulrich Drepper disagreed with Jan regarding his proposed glibc change (from 2009). An upstream ChangeLog entry from Oct 2014 shows that Jan and Pedro added upstream test gdb.base/vdso-warning.exp. Also, at that time, new code was added to GDB for handling the vdso problem. See upstream PR 14466: https://sourceware.org/bugzilla/show_bug.cgi?id=14466) All further/subsequent changes to the local patch gdb-core-open-vdso-warning.patch are rebase related. Bottom line is that the remaining tests in gdb.base/solib-symbol.exp are covered by an existing upstream test. The upstream test also handles the core file case which had also once been handled by this local test.
2024-06-15 02:28:34 +00:00
Patch016: gdb-archer-next-over-throw-cxx-exec.patch
# [delayed-symfile] Test a backtrace regression on CFIs without DIE (BZ 614604).
#=fedoratest
Remove gdb-core-open-vdso-warning.patch The tests added by this patch are similar to those of upstream test gdb.base/vdso-warning.exp. I think that the upstream patch provides better coverage in that it also provides tests involving core files. This patch started out as a change to gdb in Jan 2010 changing gdb/solib-svr4.c. There were no tests included in this initial commit. Tests were added in a commit from June 19, 2012, changing files gdb.base/solib-symbol.exp and gdb.base/corefile.exp. There were also changes made to gdb/solib.c. Tweaks to the test cases were made in commits from July 3, 2012, July 6, 2012, and Jan 19, 2013. Many, maybe all, of the solib-svr4.c and solib.c changes were removed in a commit from Feb 7, 2014. The gdb.base/corefile.exp changes were removed at the same time. There is no explanation in the log for why this was done. However, after reading some gdb-patches discussion from that period, it appears that Jan believed that the correct fix was in glibc and that having a workaround in gdb weakened the argument for what he believed to be a proper fix in glibc. Roland McGrath and Ulrich Drepper disagreed with Jan regarding his proposed glibc change (from 2009). An upstream ChangeLog entry from Oct 2014 shows that Jan and Pedro added upstream test gdb.base/vdso-warning.exp. Also, at that time, new code was added to GDB for handling the vdso problem. See upstream PR 14466: https://sourceware.org/bugzilla/show_bug.cgi?id=14466) All further/subsequent changes to the local patch gdb-core-open-vdso-warning.patch are rebase related. Bottom line is that the remaining tests in gdb.base/solib-symbol.exp are covered by an existing upstream test. The upstream test also handles the core file case which had also once been handled by this local test.
2024-06-15 02:28:34 +00:00
Patch017: gdb-test-bt-cfi-without-die.patch
# [archer-tromey-delayed-symfile] New test gdb.dwarf2/dw2-aranges.exp.
#=fedoratest
Remove gdb-core-open-vdso-warning.patch The tests added by this patch are similar to those of upstream test gdb.base/vdso-warning.exp. I think that the upstream patch provides better coverage in that it also provides tests involving core files. This patch started out as a change to gdb in Jan 2010 changing gdb/solib-svr4.c. There were no tests included in this initial commit. Tests were added in a commit from June 19, 2012, changing files gdb.base/solib-symbol.exp and gdb.base/corefile.exp. There were also changes made to gdb/solib.c. Tweaks to the test cases were made in commits from July 3, 2012, July 6, 2012, and Jan 19, 2013. Many, maybe all, of the solib-svr4.c and solib.c changes were removed in a commit from Feb 7, 2014. The gdb.base/corefile.exp changes were removed at the same time. There is no explanation in the log for why this was done. However, after reading some gdb-patches discussion from that period, it appears that Jan believed that the correct fix was in glibc and that having a workaround in gdb weakened the argument for what he believed to be a proper fix in glibc. Roland McGrath and Ulrich Drepper disagreed with Jan regarding his proposed glibc change (from 2009). An upstream ChangeLog entry from Oct 2014 shows that Jan and Pedro added upstream test gdb.base/vdso-warning.exp. Also, at that time, new code was added to GDB for handling the vdso problem. See upstream PR 14466: https://sourceware.org/bugzilla/show_bug.cgi?id=14466) All further/subsequent changes to the local patch gdb-core-open-vdso-warning.patch are rebase related. Bottom line is that the remaining tests in gdb.base/solib-symbol.exp are covered by an existing upstream test. The upstream test also handles the core file case which had also once been handled by this local test.
2024-06-15 02:28:34 +00:00
Patch018: gdb-test-dw2-aranges.patch
# Testcase for `Setting solib-absolute-prefix breaks vDSO' (BZ 818343).
#=fedoratest
Patch019: gdb-rhbz-818343-set-solib-absolute-prefix-testcase.patch
# Import regression test for `gdb/findvar.c:417: internal-error:
# read_var_value: Assertion `frame' failed.' (RH BZ 947564) from RHEL 6.5.
#=fedoratest
Patch020: gdb-rhbz947564-findvar-assertion-frame-failed-testcase.patch
# Fix 'memory leak in infpy_read_memory()' (RH BZ 1007614)
#=fedoratest
Patch021: gdb-rhbz1007614-memleak-infpy_read_memory-test.patch
# Fix 'gdb gives highly misleading error when debuginfo pkg is present,
# but not corresponding binary pkg' (RH BZ 981154).
#=push+jan
Patch022: gdb-6.6-buildid-locate-misleading-warning-missing-debuginfo-rhbz981154.patch
# Testcase for '[SAP] Recursive dlopen causes SAP HANA installer to
# crash.' (RH BZ 1156192).
#=fedoratest
Patch023: gdb-rhbz1156192-recursive-dlopen-test.patch
# Fix '`catch syscall' doesn't work for parent after `fork' is called'
# (Philippe Waroquiers, RH BZ 1149205).
#=fedoratest
Patch024: gdb-rhbz1149205-catch-syscall-after-fork-test.patch
# Fix '[ppc64] and [s390x] wrong prologue skip on -O2 -g code' (Jan
# Kratochvil, RH BZ 1084404).
#=fedoratest
Patch025: gdb-rhbz1084404-ppc64-s390x-wrong-prologue-skip-O2-g-3of3.patch
# [aarch64] Fix hardware watchpoints (RH BZ 1261564).
#=fedoratest
Patch026: gdb-rhbz1261564-aarch64-hw-watchpoint-test.patch
Rewrite (and rename) gdb-libexec-add-index.patch 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.
2023-05-04 13:48:16 +00:00
# Update gdb-add-index.sh such that, when the GDB environment
# variable is not set, the script is smarter than just looking for
# 'gdb' in the $PATH.
#
Rewrite (and rename) gdb-libexec-add-index.patch 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.
2023-05-04 13:48:16 +00:00
# The actual search order is now: /usr/bin/gdb.minimal, gdb (in the
# $PATH), then /usr/libexec/gdb.
#
# For the rationale of looking for gdb.minimal see:
#
# https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot
Rewrite (and rename) gdb-libexec-add-index.patch 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.
2023-05-04 13:48:16 +00:00
#
#=fedora
Patch027: gdb-add-index.patch
# Back-port upstream commit 1f0fab7ff86 as part of a fix for
# non-deterministic gdb-index generation (RH BZ 2232086).
Patch028: gdb-rhbz2232086-refactor-selftest-support.patch
# Back-port upstream commit aa19bc1d259 as part of a fix for
# non-deterministic gdb-index generation (RH BZ 2232086).
Patch029: gdb-rhbz-2232086-reduce-size-of-gdb-index.patch
# Back-port upstream commit acc117b57f7 as part of a fix for
# non-deterministic gdb-index generation (RH BZ 2232086).
Patch030: gdb-rhbz-2232086-cpp-ify-mapped-symtab.patch
# Back-port upstream commit aff250145af as part of a fix for
# non-deterministic gdb-index generation (RH BZ 2232086).
Patch031: gdb-rhbz-2232086-generate-gdb-index-consistently.patch
# Back-port upstream commit 3644f41dc80 as part of a fix for
# non-deterministic gdb-index generation (RH BZ 2232086).
Patch032: gdb-rhbz-2232086-generate-dwarf-5-index-consistently.patch
Patch033: gdb-rhbz2250652-gdbpy_gil.patch
Patch034: gdb-rhbz2250652-avoid-PyOS_ReadlineTState.patch
Patch035: gdb-ftbs-swapped-calloc-args.patch
# Backport upstream workaround for GCC 14 problem which cause assertion
# failures in GDB.
Patch036: gdb-rhbz2261580-intrusive_list-assertion-fix.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit 7628a997f27.
Patch037: gdb-sync-coffread-with-elfread.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit 27807da5849.
Patch038: gdb-merge-debug-symbol-lookup.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit 6234ba17598.
Patch039: gdb-refactor-find-and-add-separate-symbol-file.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit 661d98a3331.
Patch040: gdb-add-missing-debug-ext-lang-hook.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit 8f6c452b5a4.
Patch041: gdb-add-missing-debug-info-python-hook.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit 7db795bc67a.
Patch042: gdb-remove-use-of-py-isascii
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit 1146d27749f.
Patch043: gdb-remove-path-in-test-name.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit e8c3dafa5f5.
Patch044: gdb-do-not-import-py-curses-ascii-module.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit dd5516bf98f.
Patch045: gdb-reformat-missing-debug-py-file.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Backport upstream commit 7d21600b31fe.
Patch046: gdb-handle-no-python-gdb-module.patch
switch rpm suggestion feature to a Python extension This commit backports several patches from upstream GDB: 7d21600b31f dd5516bf98f e8c3dafa5f5 1146d27749f 7db795bc67a 8f6c452b5a4 661d98a3331 6234ba17598 27807da5849 7628a997f27 These commits provide a new Python API which allows users to catch the case where GDB tries to load an objfile, but can't find any debug information. I've then added a new patch which uses this Python API to hook into GDB and make suggestions about RPMs to install that could provide missing debug information, this should replace some of the rpm suggestion functionality that is currently implemented within GDB's C++ code, as such I've deleted all of the code related to opening librpm and querying the RPM database. There is still code in GDB which will make suggestions about installing RPMs based on the path to the build-id symlink for the file. This code is hit when a user tries to open a core-file and the corresponding executable can't be found, or if a shared library required by the core-file isn't found. In these cases the librpm lookup would always fail anyway and we'd just suggest that the user try to install the required package based on the path to the build-id symlink, e.g.: Missing separate debuginfo for the main executable file. Try: yum --enablerepo='*debug*' install /usr/local/lib/debug/.build-id/bf/c9fbd13046db58c28ba332e6c991240e775c96 This should still work just as it did before. Now GDB no longer links against librpm I'm able to remove all the librpm related stuff from the configure scripts, which is a nice cleanup. There are a couple of patches: gdb-6.6-buildid-locate-rpm-librpm-workaround.patch gdb-6.6-buildid-locate-rpm.patch which deal exclusively with updating code (added in earlier patches) related to the use of librpm from GDB's C++ code, these patches are removed by this commit. Other patches are changed either by the removal of the librpm code, or as a consequence of that code having been removed. I've also taken the opportunity to fix up some of the test cases which only exist in the Fedora tree so that they will run again. This is mostly just updating the tests to match upstream GDB's current testsuite infrastructure, these are all pretty minor fixes.
2024-03-08 14:21:56 +00:00
# Not a backport. Add a new script which hooks into GDB and suggests
# RPMs to install when GDB finds an objfile with no debug info.
Patch047: gdb-add-rpm-suggestion-script.patch
# Update x86 disassembler
Patch048: gdb-rhbz2277160-apx-disasm.patch
# backport of upstream commit 91874afabcd
# This (somehow) solves a double-free when reading minimal symbols
Patch049: gdb-rhel2295897-pre-read-DWZ-file-in-DWARF-reader.patch