aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-03-09GDB/testsuite: Remove a stray backslash from gdb.base/settings.expMaciej W. Rozycki1-1/+1
Remove a stray trailing backslash from `test-integer' in settings.exp. It is harmless as only white space follows in the next line before the closing brace, so it merely swallows the newline character, but it may look confusing to the reader.
2022-03-09* gdb/doc/gdb.texinfo (Requirements): Fix a typo.Christina Schimpe1-1/+1
Copyright-paperwork-exempt: yes
2022-03-09Constant fold view increment expressionsAlan Modra2-6/+14
The idea here is to replace expressions like v + 1 + 1 + 1 with v + 3. * dwarf2dbg.c (set_or_check_view): Remove useless assertion. Resolve multiple view increments. * testsuite/gas/elf/dwarf2-18.d: Don't xfail mep.
2022-03-09Reduce duplicated symbol_clone_if_forward_ref workAlan Modra1-3/+8
* symbol.c (struct symbol_flags): Add forward_resolved. (symbol_entry_find): Update needle initialisation. (symbol_clone_if_forward_ref): Do no work when forward_resolved is already set. Set forward_resolved.
2022-03-08gdb: Try searching for auto-load script using .gnu_debuglinkAaron Merey1-12/+52
If an auto-load script cannot be found and objfile is a separate debuginfo whose filename does not match the name found in the parent file's .gnu_debuglink section, then repeat the search using the parent's filename where the last component is replaced with the .gnu_debuglink name. For example if the parent's filename is "/usr/lib/libxyz.so" and the name in its .gnu_debuglink section is "libxyz.so.debug", then if no auto-load script is otherwise found the search will be repeated with the filename "/usr/lib/libxyz.so.debug". This helps gdb locate auto-load scripts when debuginfo files do not have the expected filename, such as when they are aquired from debuginfod.
2022-03-09Automatic date update in version.inGDB Administrator1-1/+1
2022-03-08PR gdb/27876 - debuginfod-downloaded source files don't pass proper fullname ↵Aaron Merey1-2/+3
across mi / (gdb)info source Source files downloaded from debuginfod currently use their original DWARF filename as their "fullname". This causes a mismatch between the fullname and the actual location of the source file in the debuginfod client cache. MI consumers such as VSCode will fail to open debuginfod-downloaded source files due to this. Also 'info source' will fail to include the true paths of these files. To fix this, use the debuginfod cache path as the fullname for debuginfod- downloaded source files.
2022-03-08gdb/mi: preserve user selected thread and frame when invoking MI commandsJan Vrany4-63/+191
Fix for PR gdb/20684. When invoking MI commands with --thread and/or --frame, the user selected thread and frame was not preserved: (gdb) info thread &"info thread\n" ~" Id Target Id Frame \n" ~"* 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n" ~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n" ~" 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n" ^done (gdb) info frame &"info frame\n" ~"Stack level 0, frame at 0x7fffffffdf90:\n" ~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n" ~" source language c.\n" ~" Arglist at 0x7fffffffdf80, args: \n" ~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n" ~" Saved registers:\n " ~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n" ^done (gdb) -stack-info-depth --thread 3 ^done,depth="4" (gdb) info thread &"info thread\n" ~" Id Target Id Frame \n" ~" 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n" ~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n" ~"* 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n" ^done (gdb) info frame &"info frame\n" ~"Stack level 0, frame at 0x7ffff742dee0:\n" ~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n" ~" called by frame at 0x7ffff742df00\n" ~" source language c.\n" ~" Arglist at 0x7ffff742ded0, args: \n" ~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n" ~" Saved registers:\n " ~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n" ^done (gdb) This caused problems for frontends that provide access to CLI because UI may silently change the context for CLI commands (as demonstrated above). This commit fixes the problem by restoring thread and frame in mi_cmd_execute (). With this change, there are only two GDB/MI commands that can change user selected context: -thread-select and -stack-select-frame. This allows us to remove all and rather complicated logic of notifying about user selected context change from mi_execute_command (), leaving it to these two commands themselves to notify. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20684
2022-03-08gdb: announce upcoming removal of Python 2 support from gdbAndrew Burgess1-0/+4
As has been discussed here: https://sourceware.org/pipermail/gdb-patches/2022-January/184910.html Python 2 support will be removed from GDB after GDB 12 has branched. This commit places an entry in the NEWS file to inform users of this decision.
2022-03-08Automatic date update in version.inGDB Administrator1-1/+1
2022-03-07gdb/testsuite: add new test for comparing char types in PythonAndrew Burgess1-0/+34
There's an interesting property of the 'char' type in C and C++, the three types 'char', 'unsigned char', and 'signed char', are all considered distinct. In contrast, and 'int' is signed by default, and so 'int' and 'signed int' are considered the same type. This commit adds a test to ensure that this edge case is visible to a user from Python. It is worth noting that for any particular compiler implementation (or the flags a compiler was invoked with), a 'char' will be either signed or unsigned; it has to be one or the other, and a user can access this information by using the Type.is_signed property. However, for something like function overload resolution, the 'char' type is considered distinct from the signed and unsigned variants. There's no change to GDB with this commit, this is just adding a new test to guard some existing functionality.
2022-03-07gdb/python: add Type.is_signed propertyAndrew Burgess5-1/+80
Add a new read-only property, Type.is_signed, which is True for signed types, and False otherwise. This property should only be read on types for which Type.is_scalar is true, attempting to read this property for non-scalar types will raise a ValueError. I chose 'is_signed' rather than 'is_unsigned' in order to match the existing Architecture.integer_type method, which takes a 'signed' parameter. As far as I could find, that was the only existing signed/unsigned selector in the Python API, so it seemed reasonable to stay consistent.
2022-03-07gdb/python: add Type.is_scalar propertyAndrew Burgess5-1/+65
Add a new read-only property which is True for scalar types, otherwise, it's False.
2022-03-07gdb/mi: add --no-connection to MI -add-inferior commandAndrew Burgess5-23/+91
Following on from the previous commit, where the -add-inferior command now uses the same connection as the current inferior, this commit adds a --no-connection option to -add-inferior. This new option matches the existing option of the same name for the CLI version of add-inferior; the new inferior is created with no connection. I've added a new 'connection' field to the MI output of -add-inferior, which includes the connection number and short name. I haven't included the longer description field, this is the MI after all. My expectation would be that if the frontend wanted to display all the connection details then this would be looked up from 'info connection' (or the MI equivalent if/when such a command is added). The existing -add-inferior tests are updated, as are the docs.
2022-03-07gdb/mi: fix regression in mi -add-inferior commandUmair Sair5-4/+141
Prior to the multi-target support commit: commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2 Date: Fri Jan 10 20:06:08 2020 +0000 Multi-target support When a new inferior was added using the MI -add-inferior command, the new inferior would be using the same target as all the other inferiors. This makes sense, GDB only supported a single target stack at a time. After the above commit, each inferior has its own target stack. To maintain backward compatibility, for the CLI add-inferior command, when a new inferior is added the above commit has the new inferior inherit a copy of the target stack from the current inferior. Unfortunately, this same backward compatibility is missing for the MI. This commit fixes this oversight. Now, when the -add-inferior MI command is used, the new inferior will inherit a copy of the target stack from the current inferior.
2022-03-07Deprecate dbx modeTom Tromey2-0/+5
GDB has a dbx emulation mode that adds a few aliases and helper commands. This mode is barely documented and is very superficial besides. I suspect it is rarely used, and I would like to propose deprecating it for GDB 12, and then removing it in GDB 13.
2022-03-07Remove unnecessary inferior lookup in infrun:handle_onePedro Alves1-2/+1
infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we already have a thread pointer handy, and the thread has a pointer to the inferior. This commit removes the unnecessary lookup. Change-Id: I2ae18601dd75346c6c91068e9a4f9a6484fb3339
2022-03-07Fix bug in ada_print_floatingTom Tromey2-0/+10
ada_print_floating rewrites a floating-point string representation to conform to Ada syntax. However, if you managed to get a floating point error, you might see: (gdb) print whatever $2 = <invalid float valu.0e> What's happening here is that ada_print_floating doesn't recognize this error case, and proceeds to modify the error text. This patch fixes this problem.
2022-03-07Implement real literal extension for AdaTom Tromey5-20/+174
Sometimes it is convenient to be able to specify the exact bits of a floating-point literal. For example, you may want to set a floating-point register to a denormalized value, or to a particular NaN. In C, you can do this by combining the "{}" cast with an array literal, like: (gdb) p {double}{0x576488BDD2AE9FFE} $1 = 9.8765449999999996e+112 This patch adds a somewhat similar idea to Ada. It extends the lexer to allow "l" and "f" suffixes in a based literal. The "f" indicates a floating-point literal, and the "l"s control the size of the floating-point type. Note that this differs from Ada's based real literals. I believe those can also be used to control the bits of a floating-point value, but they are a bit more cumbersome to use (simplest is binary but that's also very lengthy). Also, these aren't implemented in GDB. I chose not to allow this extension to work with based integer literals with exponents. That didn't seem very useful.
2022-03-07Fix Ada integer literals with exponentsTom Tromey2-3/+42
While working on another patch, I noticed that Ada integer literals with exponents did not work. For example, with one form you get an error: (gdb) print 8e2 Invalid digit `e' in based literal And with another form you get an incorrect value: (gdb) print 16#8#e2 $2 = 8 This patch fixes the bugs and adds tests.
2022-03-07Fix gdb.ada/arrayptr.exp resultsTom Tromey1-24/+13
PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12, but fails with minimal encodings in earlier versions. This patch updates the test to try to report the results correctly. I tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12 built from git trunk sometime relatively recently. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28115
2022-03-07Handle non-ASCII identifiers in AdaTom Tromey19-21/+2262
Ada allows non-ASCII identifiers, and GNAT supports several such encodings. This patch adds the corresponding support to gdb. GNAT encodes non-ASCII characters using special symbol names. For character sets like Latin-1, where all characters are a single byte, it uses a "U" followed by the hex for the character. So, for example, thorn would be encoded as "Ufe" (0xFE being lower case thorn). For wider characters, despite what the manual says (it claims Shift-JIS and EUC can be used), in practice recent versions only support Unicode. Here, characters in the base plane are represented using "Wxxxx" and characters outside the base plane using "WWxxxxxxxx". GNAT has some further quirks here. Ada is case-insensitive, and GNAT emits symbols that have been case-folded. For characters in ASCII, and for all characters in non-Unicode character sets, lower case is used. For Unicode, however, characters that fit in a single byte are converted to lower case, but all others are converted to upper case. Furthermore, there is a bug in GNAT where two symbols that differ only in the case of "Y WITH DIAERESIS" (and potentially others, I did not check exhaustively) can be used in one program. I chose to omit handling this case from gdb, on the theory that it is hard to figure out the logic, and anyway if the bug is ever fixed, we'll regret having a heuristic. This patch introduces a new "ada source-charset" setting. It defaults to Latin-1, as that is GNAT's default. This setting controls how "U" characters are decoded -- W/WW are always handled as UTF-32. The ada_tag_name_from_tsd change is needed because this function will read memory from the inferior and interpret it -- and this caused an encoding failure on PPC when running a test that tries to read uninitialized memory. This patch implements its own UTF-32-based case folder. This avoids host platform quirks, and is relatively simple. A short Python program to generate the case-folding table is included. It simply relies on whatever version of Unicode is used by the host Python, which seems basically acceptable. Test cases for UTF-8, Latin-1, and Latin-3 are included. This exercises most of the new code paths, aside from Y WITH DIAERESIS as noted above.
2022-03-07Define HOST_UTF32 in charset.hTom Tromey2-8/+10
rust-parse.c has a #define for the host-specific UTF-32 charset name. A later patch needs the same thing, so this patch moves the definition to charset.h for easier reuse.
2022-03-07Let phex and phex_nz handle sizeof_l==1Tom Tromey1-0/+8
Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let this case fall through to the default case. However, a subsequent patch in this series needs this case to work correctly. I looked at all calls to these functions that pass a 1 for the sizeof_l parameter. The only such case seems to be correct with this change.
2022-03-07Don't pre-size result string in ada_decodeTom Tromey1-14/+6
Currently, ada_decode pre-sizes the output string, filling it with 'X' characters. However, it's a bit simpler and more flexible to let std::string do the work here, and simply append characters to the string as we go. This turns out to be useful for a subsequent patch.
2022-03-07Simplify a regular expression in ada-lex.lTom Tromey1-1/+1
ada-lex.l uses "%option case-insensitive", so there is no need for regular expressions to match upper case.
2022-03-07Automatic date update in version.inGDB Administrator1-1/+1
2022-03-06MIPS/opcodes: Fix alias annotation for branch instructionsMaciej W. Rozycki15-7/+216
Correct issues with INSN2_ALIAS annotation for branch instructions: - regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for BEQ/L and BNE/L respectively with the `rs' operand equal to $0, - microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for BEQ and BNE respectively with the `rt' operand equal to $0, - regular MIPS BAL assembly instruction is an idiom for architecture levels of up to the MIPSr5 ISA and a machine instruction on its own from the MIPSr6 ISA up. Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug: $ mips-linux-gnu-objdump -m mips:isa64r6 -M no-aliases -d bal.o bal.o: file format elf32-tradlittlemips Disassembly of section .text: 00000000 <foo>: 0: 04110000 0x4110000 ... $ Add test cases accordingly. Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel. 2022-03-06 Maciej W. Rozycki <macro@orcam.me.uk> binutils/ * testsuite/binutils-all/mips/mips1-branch-alias.d: New test. * testsuite/binutils-all/mips/mips1-branch-noalias.d: New test. * testsuite/binutils-all/mips/mips2-branch-alias.d: New test. * testsuite/binutils-all/mips/mips2-branch-noalias.d: New test. * testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test. * testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New test. * testsuite/binutils-all/mips/micromips-branch-alias.d: New test. * testsuite/binutils-all/mips/micromips-branch-noalias.d: New test. * testsuite/binutils-all/mips/mips-branch-alias.s: New test source. * testsuite/binutils-all/mips/micromips-branch-alias.s: New test source. * testsuite/binutils-all/mips/mips.exp: Run the new tests. 2022-03-06 Sagar Patel <sagarmp@cs.unc.edu> Maciej W. Rozycki <macro@orcam.me.uk> opcodes/ * mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions. * micromips-opc.c (micromips_opcodes): Likewise for "beqz" and "bnez" instructions.
2022-03-06Use function view when iterating over block symbolsTom Tromey3-78/+38
This changes iterate_over_block_local_vars and iterate_over_block_arg_vars to take a gdb::function_view rather than a function pointer and a user-data. In one spot, this allows us to remove a helper structure and helper function. In another spot, this looked more complicated, so I changed the helper function to be an "operator()" -- also a simplification, just not as big.
2022-03-06Simplify hppa-tdep.c use of objfile_keyTom Tromey1-23/+10
I happened to notice a couple of unnecessary casts in hppa-tdep.c, and then I saw that the use of objfile_key could be simplified -- removing some code and using the default deleter rather than noop_deleter. Tested by rebuilding. Let me know what you think.
2022-03-06gdb: constify parameter of value_copySimon Marchi2-5/+10
In a following patch, I have a const value I want to copy using a value_copy. However, value_copy takes a non-const source value, at the moment. Change the paramter to be const, If the source value is not lazy, we currently call value_contents_all_raw, which calls allocate_value_contents, to get a view on the contents. They both take a non-const value, that's a problem. My first attempt at solving it was to add a const version of value_contents_all_raw, make allocate_value_contents take a const value, and either: - make value::contents mutable - make allocate_value_contents cast away the const The idea being that allocating the value contents buffer does modify the value at the bit level, but logically that doesn't change its state. That was getting a bit complicated, so what I ended up doing is make value_copy not call value_contents_all_raw. We know at this point that the value is not lazy, so value::contents must have been allocate already. Change-Id: I3741ab362bce14315f712ec24064ccc17e3578d4
2022-03-06gdb: remove internalvar_funcs::destroySimon Marchi9-19/+0
No kind of internal var uses it remove it. This makes the transition to using a variant easier, since we don't need to think about where this should be called (in a destructor or not), if it can throw, etc. Change-Id: Iebbc867d1ce6716480450d9790410d6684cbe4dd
2022-03-06Automatic date update in version.inGDB Administrator1-1/+1
2022-03-05Automatic date update in version.inGDB Administrator1-1/+1
2022-03-04Mark vDSO as not a fileTom Tromey1-1/+1
The vDSO objfile is not a real file, so mark it as such. I noticed this because, when playing with debuginfod, I saw: Downloading 0.01 MB separate debug info for /tmp/system-supplied DSO at 0x7ffff7fc9000 That "/tmp" is wrong -- it's just gdb's cwd. This patch corrects the problem, resulting in: Downloading 0.01 MB separate debug info for system-supplied DSO at 0x7ffff7fc9000 Regression tested on x86-64 Fedora 34.
2022-03-04binutils/readelf: fix indentation in process_dynamic_sectionSimon Marchi2-6/+10
Clangd shows a warning about misleading indentation in this file, fix it. binutils/ChangeLog: * readelf.c (process_dynamic_section): Fix indentation. Change-Id: I43a7f4f4c75dd080af614222b980526f5debf297
2022-03-04gdb: Use a typedef's scoped type name to identify local typedefsChristina Schimpe3-19/+95
GDB prints the wrong type for typedefs in case there is another typedef available for the same raw type (gdb/16040). The reason is that the current hashmap based substitution mechanism always compares the target type of a typedef and not its scoped name. The original output of GDB for a program like ~~~~ namespace ns { typedef double scoped_double; } typedef double global_double; class TypedefHolder { public: double a; ns::scoped_double b; global_double c; private: typedef double class_double; class_double d; double method1(ns::scoped_double) { return 24.0; } double method2(global_double) { return 24.0; } }; int main() { TypedefHolder th; return 0; } ~~~~ is ~~~~ (gdb) b 27 Breakpoint 1 at 0x1131: file TypedefHolder.cc, line 27. (gdb) r Starting program: /tmp/typedefholder Breakpoint 1, main () at TypedefHolder.cc:27 27 return 0; (gdb) ptype th type = class TypedefHolder { public: class_double a; class_double b; class_double c; private: class_double d; class_double method1(class_double); class_double method2(class_double); typedef double class_double; } ~~~~ Basically all attributes of a class which have the raw type "double" are substituted by "class_double". With the patch the output is the following ~~~~ type = class TypedefHolder { public: double a; ns::scoped_double b; global_double c; private: class_double d; double method1(ns::scoped_double); double method2(global_double); typedef double class_double; } ~~~~
2022-03-04RISC-V: make .insn actually work for 64-bit insnsJan Beulich3-1/+9
Presently in this case, due to an undefined behavior shift, at least with x86 cross builds I'm observing: Error: value conflicts with instruction length `8,0x0000003f' Eliminate the UB and extend the respective testcase.
2022-03-04x86: drop redundant x86-64-code16-2 testJan Beulich2-5/+0
The code16-2 test is already meaningless enough as a gas test, identical to this one, and is run uniformly for all ELF targets anyway.
2022-03-04Automatic date update in version.inGDB Administrator1-1/+1
2022-03-03Fix typo in last change.Roland McGrath1-1/+1
2022-03-03Avoid conflict with gnulib open/close macros.Roland McGrath4-9/+9
On some systems, the gnulib configuration will decide to define open and/or close as macros to replace the POSIX C functions. This interferes with using those names in C++ class or namespace scopes. gdbsupport/ * event-pipe.cc (event_pipe::open): Renamed to ... (event_pipe::open_pipe): ... this. (event_pipe::close): Renamed to ... (event_pipe::close_pipe): ... this. * event-pipe.h (class event_pipe): Updated. gdb/ * inf-ptrace.h (async_file_open, async_file_close): Updated. gdbserver/ * gdbserver/linux-low.cc (linux_process_target::async): Likewise.
2022-03-04Adjust ld ctf test for 32-bit targetsAlan Modra1-1/+1
powerpc-linux, and I suspect other 32-bit targets, report "aligned at 0x4" for this test. * testsuite/ld-ctf/nonrepresentable.d: Accept any alignment.
2022-03-03Update my e-mail address in the MAINTAINERS fileLuis Machado1-3/+3
Update the information accordingly.
2022-03-03gdb: testsuite: fix failed testcases in gdb.base/gdb-caching-proc.expTiezhu Yang1-0/+4
When execute the following command: make check-gdb TESTS="gdb.base/gdb-caching-proc.exp" we can see there exist some failed testcases: FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt) here are the detailed messages in gdb/testsuite/gdb.log: attach 873776 A program is being debugged already. Kill it? (y or n) n Not killed. (gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt) so handle the case "A program is being debugged already. Kill it" in can_spawn_for_attach to fix the failed testcases. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-03-03comment typo fixAlan Modra1-1/+1
2022-03-03PowerPC64 DT_RELR relative reloc addressesAlan Modra1-49/+76
Section addresses can change between ppc64_elf_size_stubs and ppc64_elf_build_stubs due to .eh_frame editing. The idea of stashing r_offset final addresses calculated in ppc64_elf_size_stubs for use by ppc64_elf_build_stubs was never a good idea. Instead, we need to keep section/offset pairs. * elf64-ppc.c (struct ppc_link_hash_table): Delete relr_addr. Add relr section/offset array. (append_relr_off): Rewrite. Update all callers. (sort_relr): New function. (ppc64_elf_size_stubs): Adjust to suit new relative reloc stash. (ppc64_elf_build_stubs): Likewise.
2022-03-03Automatic date update in version.inGDB Administrator1-1/+1
2022-03-02configure: Stop checking for PT_GETXMMREGS.John Baldwin2-57/+0
This request is present on all modern *BSD/i386 systems (those released since mid-2006), and the *BSD/i386 targets now assume it is present unconditionally.
2022-03-02i386-bsd-nat: Assume PT_GETXMMREGS is present.John Baldwin1-10/+0
NetBSD has included PT_GETXMMREGS since 1.6 released in September 2002. OpenBSD has included PT_GETXMMREGS since 3.8 released in November 2005.