aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
24 hoursAutomatic date update in version.ingdb-15-branchGDB Administrator1-1/+1
32 hoursFix loading a saved recordingHannes Domani2-0/+3
Currently you get this assertion failure if you try to execute the inferior after loading a saved recording, when no recording was done earlier in the same gdb session: ``` $ gdb -q c -ex "record restore test.rec" Reading symbols from c... [New LWP 26428] Core was generated by `/tmp/c'. Restored records from core file /tmp/test.rec. (gdb) c Continuing. ../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ``` The change in step-precsave.exp triggers this bug, since now the recording is loaded in a new gdb session, where record_full_resume_ptid was never set. The fix is to simply set record_full_resume_ptid when resuming a loaded recording. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31971 Approved-By: Guinevere Larsen <blarsen@redhat.com>
2 daysAutomatic date update in version.inGDB Administrator1-1/+1
3 daysAutomatic date update in version.inGDB Administrator1-1/+1
4 daysAutomatic date update in version.inGDB Administrator1-1/+1
5 daysAutomatic date update in version.inGDB Administrator1-1/+1
6 daysAutomatic date update in version.inGDB Administrator1-1/+1
7 daysAutomatic date update in version.inGDB Administrator1-1/+1
8 daysAutomatic date update in version.inGDB Administrator1-1/+1
9 daysAutomatic date update in version.inGDB Administrator1-1/+1
9 daysBump GDB's version number to 15.1.90.DATE-git.Joel Brobecker2-2/+2
This commit changes gdb/version.in to 15.1.90.DATE-git. This commit also makes the following changes in gdb/testsuite: * gdb.base/default.exp: Change $_gdb_minor to 2.
9 daysSet GDB version number to 15.1.gdb-15.1-releaseJoel Brobecker1-1/+1
This commit changes gdb/version.in to 15.1.
10 daysAutomatic date update in version.inGDB Administrator1-1/+1
11 daysAutomatic date update in version.inGDB Administrator1-1/+1
11 daysFix cast types for openclHannes Domani1-3/+5
The bitshift tests for opencl have these failures: print /x (signed char) 0x0f << 8 No type named signed char. (gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8 print (signed char) 0x0f << 8 No type named signed char. (gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8 Apparently opencl doesn't have the 'signed' modifier for types, only the 'unsigned' modifier. Even 'char' is guaranteed to be signed if no modifier is used, so this changes the casts to match this logic. Approved-By: Tom Tromey <tom@tromey.com>
11 daysFix 64-bit shifts where long only has 32-bit sizeHannes Domani2-4/+16
On systems where long has 32-bit size you get these failures: print 1 << (unsigned long long) 0xffffffffffffffff Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff print 1 >> (unsigned long long) 0xffffffffffffffff Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff print -1 << (unsigned long long) 0xffffffffffffffff Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff print -1 >> (unsigned long long) 0xffffffffffffffff Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff Fixed by changing the number-of-bits variable to ULONGEST. Approved-By: Tom Tromey <tom@tromey.com>
11 daysFix too-large or negative right shift of negative numbersHannes Domani2-1/+16
As seen in these test failures: print -1 >> -1 warning: right shift count is negative $N = 0 (gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1 print -4 >> -2 warning: right shift count is negative $N = 0 (gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2 Fixed by restoring the logic from before the switch to gmp. Approved-By: Tom Tromey <tom@tromey.com>
11 daysFix right shift of negative numbersHannes Domani2-2/+4
PR31590 shows that right shift of negative numbers doesn't work correctly since GDB 14: (gdb) p (-3) >> 1 $1 = -1 GDB 13 and earlier returned the correct value -2. And there actually is one test that shows the failure: print -1 >> 1 $84 = 0 (gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1 The problem was introduced with the change to gmp functions in commit 303a881f87. It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which always rounds toward zero, and the gmp docu says this: For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple bitwise right shifts. For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift treating n as two's complement the same as the bitwise logical functions do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude. So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it does right shifts for both positive and negative numbers. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31590 Approved-By: Tom Tromey <tom@tromey.com>
11 daysRestore bitshift.exp testsHannes Domani1-1/+1
Commit cdd4206647 unintentionally disabled all tests of bitshift.exp, so it actually just does this: Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ... PASS: gdb.base/bitshift.exp: complete set language === gdb Summary === # of expected passes 1 It changed the 'continue' of unsupported languages to 'return', and since ada is the first language and is unsupported, no tests were run. This changes it back to 'continue', and the following patches fix the regressions that were introduced since then unnoticed. Approved-By: Tom Tromey <tom@tromey.com>
12 daysAutomatic date update in version.inGDB Administrator1-1/+1
13 daysAutomatic date update in version.inGDB Administrator1-1/+1
2024-07-03Automatic date update in version.inGDB Administrator1-1/+1
2024-07-02Automatic date update in version.inGDB Administrator1-1/+1
2024-07-01Automatic date update in version.inGDB Administrator1-1/+1
2024-06-30Automatic date update in version.inGDB Administrator1-1/+1
2024-06-29Automatic date update in version.inGDB Administrator1-1/+1
2024-06-28Automatic date update in version.inGDB Administrator1-1/+1
2024-06-27Automatic date update in version.inGDB Administrator1-1/+1
2024-06-26Automatic date update in version.inGDB Administrator1-1/+1
2024-06-25Automatic date update in version.inGDB Administrator1-1/+1
2024-06-24Fix gdb.lookup_type for function-local typesHannes Domani3-2/+13
Looking for a type defined locally in a function doesn't work any more since the introduction of TYPE_DOMAIN: ``` (gdb) python print (gdb.lookup_type ('main()::Local')) Python Exception <class 'gdb.error'>: No type named main()::Local. Error occurred in Python: No type named main()::Local. ``` cp_search_static_and_baseclasses was simply missing a check for SEARCH_TYPE_DOMAIN, now it works again: ``` (gdb) python print (gdb.lookup_type ('main()::Local')) Local ``` Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31922 Approved-By: Tom Tromey <tom@tromey.com>
2024-06-24Include needed unordered_map headerMartin Simmons1-0/+1
Compiling on FreeBSD 13.2 with the default clang version 14.0.5 and top level configure options --with-python=/usr/local/bin/python3.9 gives this error: CXX ada-exp.o ./../binutils-gdb/gdb/ada-exp.y:100:8: error: no template named 'unordered_map' in namespace 'std' std::unordered_map<std::string, std::vector<ada_index_var_operation *>> ~~~~~^ 1 error generated. This change fixes it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31918 Approved-By: Tom Tromey <tom@tromey.com> (cherry picked from commit c702f1ad8a6a51b9c74445c77e1f6e822ba9293b)
2024-06-24Automatic date update in version.inGDB Administrator1-1/+1
2024-06-23Automatic date update in version.inGDB Administrator1-1/+1
2024-06-22Automatic date update in version.inGDB Administrator1-1/+1
2024-06-21[gdb/tdep] Fix gdb.base/watchpoint-running.exp on {arm,ppc64le}-linuxPedro Alves5-24/+49
When running test-case gdb.base/watchpoint-running on ppc64le-linux (and similar on arm-linux), we get: ... (gdb) watch global_var^M warning: Error when detecting the debug register interface. \ Debug registers will be unavailable.^M Watchpoint 2: global_var^M (gdb) FAIL: $exp: all-stop: hardware: watch global_var FAIL: $exp: all-stop: hardware: watchpoint hit (timeout) ... The problem is that ppc_linux_dreg_interface::detect fails to detect the hardware watchpoint interface, because the calls to ptrace return with errno set to ESRCH. This is a feature of ptrace: if a call is done while the tracee is not ptrace-stopped, it returns ESRCH. Indeed, in the test-case "watch global_var" is executed while the inferior is running, and that triggers the first call to ppc_linux_dreg_interface::detect. And because the detection failure is cached, subsequent attempts at setting hardware watchpoints will also fail, even if the tracee is ptrace-stopped. The way to fix this is to make sure that ppc_linux_dreg_interface::detect is called when we know that the thread is ptrace-stopped, which in the current setup is best addressed by using target-specific post_attach and post_startup_inferior overrides. However, as we can see in aarch64_linux_nat_target, that causes code duplication. Fix this by: - defining a new target hook low_init_process, called from linux_init_ptrace_procfs, which is called from both linux_nat_target::post_attach and linux_nat_target::post_startup_inferior, - adding implementations for ppc_linux_nat_target and arm_linux_nat_target that detect the hardware watchpoint interface, - replacing the aarch64_linux_nat_target implementations of post_attach and post_startup_inferior with a low_init_process implementation. Tested on ppc64le-linux, arm-linux, aarch64-linux and x86_64-linux. Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Luis Machado <luis.machado@arm.com> PR tdep/31834 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834 PR tdep/31705 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705 (cherry picked from commit 50de502a4f843310e231b3174804e95a9e7de4fc)
2024-06-21Automatic date update in version.inGDB Administrator1-1/+1
2024-06-20[gdb/python] Fix gdb.python/py-disasm.exp on arm-linuxTom de Vries3-7/+9
After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop: ... nop {0} ... we run into: ... disassemble test^M Dump of assembler code for function test:^M 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M 0x004004dc <+4>: add r11, sp, #0^M 0x004004e0 <+8>: nop {0}^M => 0x004004e4 <+12>: Python Exception <class 'ValueError'>: Buffer \ returned from read_memory is sized 0 instead of the expected 4^M ^M unknown disassembler error (error = -1)^M (gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test ... This is caused by this code in gdbpy_disassembler::read_memory_func: ... gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj, "read_memory", "KL", len, offset)); ... where len has type "unsigned int", while "K" means "unsigned long long" [1]. Fix this by using "I" instead, meaning "unsigned int". Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means "long long". Fix this by using type gdb_py_longest for offset, in combination with format character "GDB_PY_LL_ARG". Likewise in disasmpy_info_read_memory. Tested on arm-linux. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Approved-By: Tom Tromey <tom@tromey.com> PR python/31845 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 [1] https://docs.python.org/3/c-api/arg.html (cherry picked from commit 4cd214dce4579f86a85a96c882e0fc8c4d94601c)
2024-06-20Automatic date update in version.inGDB Administrator1-1/+1
2024-06-19Automatic date update in version.inGDB Administrator1-1/+1
2024-06-18Automatic date update in version.inGDB Administrator1-1/+1
2024-06-17Automatic date update in version.inGDB Administrator1-1/+1
2024-06-16Automatic date update in version.inGDB Administrator1-1/+1
2024-06-15Automatic date update in version.inGDB Administrator1-1/+1
2024-06-14Automatic date update in version.inGDB Administrator1-1/+1
2024-06-13Automatic date update in version.inGDB Administrator1-1/+1
2024-06-12fix division by zero in target_read_string()Kilian Kilger1-1/+1
Under certain circumstances, a floating point exception in target_read_string() can happen when the type has been obtained by a call to stpy_lazy_string_elt_type(). In the latter function, a call to check_typedef() has been forgotten. This makes type->length = 0 in this case. (cherry picked from commit 8130c1a430c952f65b621aee2c801316a61fab14)
2024-06-12Fix printing strings on macOS SonomaCiaran Woodward1-2/+13
On macOS sonoma, printing a string would only print the first character. For instance, if there was a 'const char *s = "foobar"', then the 'print s' command would print '$1 = "f"' rather than the expected '$1 = "foobar"'. It seems that this is due to Apple silently replacing the version of libiconv they ship with the OS to one which silently fails to handle the 'outbytesleft' parameter correctly when using 'wchar_t' as a target encoding. This specifically causes issues when using iterating through a string as wchar_iterator does. This bug is visible even if you build for an old version of macOS, but then run on Sonoma. Therefore this fix in the code applies generally to macOS, and not specific to building on Sonoma. Building for an older version and expecting forwards compatibility is a common situation on macOS. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31853 Approved-By: Tom Tromey <tom@tromey.com> (cherry picked from commit bb2981798f54e6eb30e46fb11cda2ca49561ffd3)
2024-06-12Automatic date update in version.inGDB Administrator1-1/+1
2024-06-11Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2024-07-17 00:09:16 +0000