| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| gdb-fortran-main.patch | gdb-fortran-main Daniel, Although the proper way of adding case insensitivity to symbol lookup is still under discussion, I think it might be desirable to set the main function of Fortran programs to "MAIN__" first. Because it can at least let GDB recognize that the language is Fortran after loading a Fortran executable only. What is your idea on this? Please comments. TIA! Here is the patch to set the main function in Fortran programs to "MAIN__". And followed is a patch to verify this. Tested with g77 and gfortran on x86, and g77 on ppc64. With the first patch, it reported PASS; without, report FAIL. No regression is found in gdb.fortran testcases. P.S: if there is a symbol named "MAIN__" in sources of other languages, it might disturb the debugging. But I am not sure how much it is. |
=?utf-8?b?SMOpY3RvciBPcsOzbiBNYXJ0w61uZXo=?= <zumbi@debian.org> | no | 2019-02-20 | ||
| solve_PATH_MAX_issue.patch | Patch out a PATH_MAX usage, for Hurd's benefit | Svante Signell <svante.signell@gmail.com> | yes | debian | 2013-06-08 | |
| gdb-6.5-bz185337-resolve-tls-without-debuginfo-v2.patch | gdb-6.5-bz185337-resolve-tls-without-debuginfo-v2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185337 2008-02-24 Jan Kratochvil <jan.kratochvil@redhat.com> Port to GDB-6.8pre. currently for trivial nonthreaded helloworld with no debug info up to -ggdb2 you will get: (gdb) p errno [some error] * with -ggdb2 and less "errno" in fact does not exist anywhere as it was compiled to "(*__errno_location ())" and the macro definition is not present. Unfortunately gdb will find the TLS symbol and it will try to access it but as the program has been compiled without -lpthread the TLS base register (%gs on i386) is not setup and it will result in: Cannot access memory at address 0x8 Attached suggestion patch how to deal with the most common "errno" symbol for the most common under-ggdb3 compiled programs. Original patch hooked into target_translate_tls_address. But its inferior call invalidates `struct frame *' in the callers - RH BZ 690908. https://bugzilla.redhat.com/show_bug.cgi?id=1166549 2007-11-03 Jan Kratochvil <jan.kratochvil@redhat.com> * ./gdb/dwarf2read.c (read_partial_die, dwarf2_linkage_name): Prefer DW_AT_MIPS_linkage_name over DW_AT_name now only for non-C. glibc-debuginfo-2.7-2.x86_64: /usr/lib/debug/lib64/libc.so.6.debug: <81a2> DW_AT_name : (indirect string, offset: 0x280e): __errno_location <81a8> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x2808): *__GI___errno_location |
Jan Kratochvil <jan.kratochvil@redhat.com> | no | debian | vendor, http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-6.5-bz185337-resolve-tls-without-debuginfo-v2.patch | 2019-02-20 |
| gdb-glibc-vdso-workaround.patch | [RFC] Work around PR libc/13097 "linux-vdso.so.1" #2 Hi, missed the x86_64-m32 case: gdb/ 2011-08-16 Jan Kratochvil <jan.kratochvil@redhat.com> Work around PR libc/13097. * solib.c (update_solib_list): Ignore "linux-vdso.so.1". |
=?utf-8?b?SMOpY3RvciBPcsOzbiBNYXJ0w61uZXo=?= <zumbi@debian.org> | no | 2019-02-20 | ||
| load-versioned-libcc1.patch | load-versioned-libcc1 * d/p/load-versioned-libcc1.patch: - load libcc1.so.0 instead unversioned file. |
Hector Oron <zumbi@debian.org> | no | 2019-02-20 | ||
| gdb_configure.nat.patch | gdb_configure.nat =================================================================== |
=?utf-8?b?SMOpY3RvciBPcsOzbiBNYXJ0w61uZXo=?= <zumbi@debian.org> | no | 2019-02-20 | ||
| fork-inferior-fix | =================================================================== | no | ||||
| fix-build.patch | =================================================================== | invalid | Debian | 2022-10-12 | ||
| fix-crash-in-inside_main_func.patch | gdb 13.1 crashes while running the rust compiler's debugger tests. The crash has a number of causes. First, the rust compiler still uses the C++-like _Z mangling, but with its own twist -- some hex digits added to the end of a symbol. So, while gdb finds the correct name of "main": (top-gdb) p name $13 = 0x292e0c0 "rustc_gdb_1031745::main" It isn't found in the minsyms, because C++ demangling yields: [99] t 0x90c0 _ZN17rustc_gdb_10317454main17h5b5be7fe16a97225E section .text rustc_gdb_1031745::main::h5b5be7fe16a97225 zko06yobckx336v This could perhaps be fixed. I also filed a new PR to suggest preferring the linkage name of the main program. Next, the rust compiler emits both a DW_TAG_subprogram and a DW_TAG_namespace for "main". This happens because the file is named "main.rs" -- i.e., the bug is specific to the source file name. The crash also seems to require the nested function inside of 'main', at least for me. The namespace always is generated, but perhaps this changes the ordering in the DWARF. When inside_main_func looks up the main symbol, it finds the namespace symbol rather than the function. (I filed a bug about fixing gdb's symbol tables -- long overdue.) Meanwhile, as I think it's important to fix this crash sooner rather than later, this patch changes inside_main_func to check that the symbol that is found is LOC_BLOCK. This perhaps should have been done in the first place, anyway. |
yes | upstream | |||
| aarch64-pauth-registers.patch | [PATCH] aarch64: Check for valid inferior thread/regcache before reading pauth registers There were reports of gdb throwing internal errors when calling inferior_thread ()/get_current_regcache () on a system with Pointer Authentication enabled. In such cases, gdb produces the following backtrace, or a variation of it (for gdb's with the non-address removal implemented only in the aarch64-linux-tdep.c file). ../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. |
Luis Machado <luis.machado@arm.com> | no | 2023-03-24 |