| 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 |