With gdb 15.1, python sys.exit no longer makes gdb exit:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
Python Exception <class 'SystemExit'>: 2
Error occurred in Python: 2
$1 = 123
0
...
This is a change in behaviour since commit a207f6b3a3 ("Rewrite "python"
command exception handling"), first available in gdb 15.1.
This patch reverts to the old behaviour by handling PyExc_SystemExit in
gdbpy_handle_exception, such what we have instead:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
2
...
Tested on x86_64-linux, with python 3.6 and 3.13.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31946
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946
After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds
this debug info:
...
<1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type)
<120> DW_AT_specification: <0x130>
<2><124>: Abbrev Number: 4 (DW_TAG_enumerator)
<125> DW_AT_name : val1
<12a> DW_AT_const_value : 1
<2><12b>: Abbrev Number: 0
<1><12c>: Abbrev Number: 5 (DW_TAG_namespace)
<12d> DW_AT_name : ns
<2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type)
<131> DW_AT_name : e
<133> DW_AT_type : <0x118>
<137> DW_AT_declaration : 1
...
I run into an assertion failure:
...
(gdb) file enum-type^M
Reading symbols from enum-type...^M
cooked-index.h:214: internal-error: get_parent: \
Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M
...
This was reported in PR32160 comment 1.
This is a regression since commit 4e417d7bb1 ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Fix this by reverting the commit.
[ Also drop the kfails for PR31900 and PR32158, which are regressions by that
same commit. ]
That allows us to look at the output of "maint print objfiles", and for val1
we get an entry without parent:
...
[27] ((cooked_index_entry *) 0x7fbbb4002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x124
parent: ((cooked_index_entry *) 0)
...
which is incorrect, as noted in that same comment, but an improvement over the
assertion failure, and I don't think that ever worked. This is to be
addressed in a follow-up patch.
Reverting the commit begs the question: what was it trying to fix in the first
place, and do we need a different fix? I've investigated this and filed
PR32160 to track this.
My guess is that the commit was based on a misunderstand of what we track
in cooked_indexer::m_die_range_map.
Each DIE has two types of parent DIEs:
- a DIE that is the parent as indicated by the tree structure in which DIEs
occur, and
- a DIE that represent the parent scope.
In most cases, these two are the same, but some times they're not.
The debug info above demonstrates such a case. The DIE at 0x11f:
- has a tree-parent: the DIE representing the CU, and
- has a scope-parent: DIE 0x12c representing namespace ns.
In cooked_indexer::m_die_range_map, we track scope-parents, and the commit
tried to add a tree-parent instead.
So, I don't think we need a different fix, and propose we backport the reversal
for gdb 15.2.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160
(cherry picked from commit a2860473ef)
Consider test-case:
...
namespace ns {
enum class ec {
val2 = 2
};
}
int main () {
return (int)ns::ec::val2;
}
...
compiled with debug info:
...
$ g++ test.c -g
...
When looking at the cooked index entry for val2 using "maint print objfiles",
we get:
...
[7] ((cooked_index_entry *) 0x7f8ecc002ef0)
name: val2
canonical: val2
qualified: ns::val2
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xe9
parent: ((cooked_index_entry *) 0x7f8ecc002e90) [ns]
...
which is wrong, there is no source level entity ns::val2.
This is PR symtab/32158.
This is a regression since commit 4e417d7bb1 ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Reverting the commit on current trunk fixes the problem, and gets us instead:
...
[7] ((cooked_index_entry *) 0x7fba70002ef0)
name: val2
canonical: val2
qualified: ns::ec::val2
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xe9
parent: ((cooked_index_entry *) 0x7fba70002ec0) [ec]
...
Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
(cherry picked from commit 93a20d956e)
Consider the following test-case:
...
$ cat a.h
namespace ns {
class A {
public:
enum {
val1 = 1
};
};
}
$ cat main.c
ns::A a;
int
main (void)
{
return 0;
}
$ cat val1.c
int u1 = ns::A::val1;
...
compiled with debug info:
...
$ g++ main.c val1.c -g
...
When trying to print ns::A::val with current trunk and gdb 15.1 we get:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
There is no field named val1
...
This PR c++/31900.
With gdb 14.2 we get the expected:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
$1 = ns::A::val1
...
This is a regression since commit 4e417d7bb1 ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Reverting the commit on current trunk fixes the problem.
So how does this problem happen?
First, let's consider the current trunk, with the commit reverted.
Gdb looks for the entry ns::A::val1, and find this entry:
...
[29] ((cooked_index_entry *) 0x7f7830002ef0)
name: val1
canonical: val1
qualified: ns::A::val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x15a
parent: ((cooked_index_entry *) 0x7f7830002ec0) [A]
...
and expands the corresponding CU val1.c containing this debug info:
...
<2><14a>: Abbrev Number: 3 (DW_TAG_class_type)
<14b> DW_AT_name : A
<14d> DW_AT_byte_size : 1
<3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type)
<151> DW_AT_encoding : 7 (unsigned)
<152> DW_AT_byte_size : 4
<153> DW_AT_type : <0x163>
<159> DW_AT_accessibility: 1 (public)
<4><15a>: Abbrev Number: 5 (DW_TAG_enumerator)
<15b> DW_AT_name : val1
<15f> DW_AT_const_value : 1
<4><160>: Abbrev Number: 0
<3><161>: Abbrev Number: 0
<2><162>: Abbrev Number: 0
...
after which it finds ns::A::val1 in the expanded symtabs.
Now let's consider the current trunk as is (so, with the commit present).
Gdb looks for the entry ns::A::val1, but doesn't find it because the val1
entry is missing its parent:
...
[29] ((cooked_index_entry *) 0x7f5240002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x15a
parent: ((cooked_index_entry *) 0)
...
Then gdb looks for the entry ns::A, and finds this entry:
...
[3] ((cooked_index_entry *) 0x7f5248002ec0)
name: A
canonical: A
qualified: ns::A
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0xdd
parent: ((cooked_index_entry *) 0x7f5248002e90) [ns]
...
which corresponds to this debug info, which doesn't contain val1
due to -fno-eliminate-unused-debug-types:
...
<2><dd>: Abbrev Number: 3 (DW_TAG_class_type)
<de> DW_AT_name : A
<e0> DW_AT_byte_size : 1
<2><e3>: Abbrev Number: 0
...
Gdb expands the corresponding CU main.c, after which it doesn't find
ns::A::val1 in the expanded symtabs.
The root cause of the problem is the missing parent on the val1
cooked_index_entry, but this only becomes user-visible through the
elaborate scenario above.
Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test
for this problem that doesn't rely on expansion state or
-feliminate-unused-debug-types, but simply tests for the root cause by
grepping for ns::A::val1 in the output of "maint print objfile".
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
(cherry picked from commit 2693187cc5)
commit 868883583e
Author: Andrew Burgess <aburgess@redhat.com>
Date: Sat Mar 23 16:17:36 2024 +0000
gdb/arch: assert that X86_XSTATE_MPX is not set for x32
added
if (xcr0 & X86_XSTATE_MPX)
{
/* MPX is not available on x32. */
gdb_assert (!is_x32);
regnum = create_feature_i386_64bit_mpx (tdesc.get (), regnum);
}
But x32 is a software convention. There is no x32 mode in hardware and
CPU always returns the 64-bit mode XCR0 value for x32 processes. This
regression was fixed on master branch by
commit bf616be991 (HEAD)
Author: Andrew Burgess <aburgess@redhat.com>
Date: Thu Jan 25 14:25:57 2024 +0000
gdb/gdbserver: share some code relating to target description creation
which used the gdbserver code to clear the X86_XSTATE_MPX bit in XCR0 for
x32. Fix this regression on gdb-15-branch by clearing the X86_XSTATE_MPX
bit in XCR0 for x32 in gdb.
PR gdb/32143
* x86-linux-nat.c (x86_linux_nat_target::read_description): Clear
the X86_XSTATE_MPX bit in XCR0 for x32.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Commit a8caed5d7f handled the tombstone
value -1 used by lld (https://reviews.llvm.org/D81784). The
referenced lld commit also uses the tombstone value -2 for
pre-DWARF-v5
(e618ccbf43).
If not handled, -2 breaks the pc step range calculation and triggers
the assertion:
gdb/infrun.c:2794: internal-error: resume_1: Assertion
`pc_in_thread_step_range (pc, tp)' failed.
This commit adds -2 tombstone value and handles it in the same way as -1.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31727
Cherry-picked from e814012b2b
Approved-By: Tom Tromey <tom@tromey.com>
In PR gdb/32025, a fatal error was reported when sending a SIGINT to gdb while
disassembling.
I managed to reproduce this on aarch64-linux in a Leap 15.5 container using
this trigger patch:
...
gdb_disassembler_memory_reader::dis_asm_read_memory
(bfd_vma memaddr, gdb_byte *myaddr, unsigned int len,
struct disassemble_info *info) noexcept
{
+ set_quit_flag ();
return target_read_code (memaddr, myaddr, len);
}
...
and a simple gdb command line calling the disassemble command:
...
$ gdb -q -batch a.out -ex "disassemble main"
...
The following scenario leads to the fatal error:
- the disassemble command is executed,
- set_quit_flag is called in
gdb_disassembler_memory_reader::dis_asm_read_memory, pretending that a
user pressed ^C,
- target_read_code calls QUIT, which throws a
gdb_exception_quit,
- the exception propagation mechanism reaches c code in libopcodes and a fatal
error triggers because the c code is not compiled with -fexception.
Fix this by:
- wrapping the body of gdb_disassembler_memory_reader::dis_asm_read_memory in
catch_exceptions (which consequently needs moving to a header file), and
- reraising the caught exception in default_print_insn using QUIT.
Tested on aarch64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025
(cherry picked from commit c45c3b4162)
Using 'output' to print arrays larger than max-value-size, with only
repeating elements, can cause gdb to crash:
```
$ cat a.c:
char a[1000000];
int main()
{
return a[0];
}
$ gdb -q a
(gdb) print a
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
(gdb) output a
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
Using 'print' works, because value::record_latest sets the unavailable
bytes of the value when it's added to the value history.
But 'outout' doesn't do that, so the printing tries to access more bytes
than are available.
The original problem in PR32015 was about using 'print' of a dynamic
array in a D program.
Here the crash happens because for 'print' the value was a struct with
length/ptr fields, which is converted in d-valprint.c into an array.
So value::record_latest didn't have a chance to mark the unavailable
bytes in this case.
To make sure the unavailable bytes always match the contents, this fixes
it by marking the unavailable bytes immediately after the contents are
allocated.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
(cherry picked from commit 8fdd2b2bcd)
I noticed that the lm_info_frv objects created in frv_current_sos are
never moved to the solib object. This bug was introduced in 8971d2788e
("gdb: link so_list using intrusive_list"), which mistakenly removed the
line
sop->lm_info = std::move (li);
... probably due so a bad merge conflict resolution.
Re-add this line.
If merged in master, I would cherry-pick this to gdb-15-branch.
Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005
Approved-By: Andrew Burgess <aburgess@redhat.com>
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>
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.
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>
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>
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>
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>
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>
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>
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💯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 c702f1ad8a)
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 50de502a4f)
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 4cd214dce4)
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 8130c1a430)
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 bb2981798f)
Test behaviour of watchpoints triggered by MOPS instructions. This test
is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS
instructions rather than whatever instructions are used in the libc's
implementation of memset/memcpy/memmove.
There's a separate watched variable for each set of instructions so that
the testcase can test whether GDB correctly identified the watchpoint
that triggered in each case.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
(cherry picked from commit 55e3fcf5e5)
There are two kinds of MOPS instructions: set instructions and copy
instructions. Within each group there are variants with minor
differences in how they read or write to memory — e.g., non-temporal
read and/or write, unprivileged read and/or write and permutations of
those — but they work in the same way in terms of the registers and
regions of memory that they modify.
The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS
instructions are recorded and correctly reversed. Not all variants of the
copy and set instructions are tested, since there are many and the record
and replay target processes them in the same way.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
(cherry picked from commit ebd06ca6b9)
The AArch64 MOPS (Memory Operation) instructions provide a standardised
instruction sequence to perform a memset, memcpy or memmove. A sequence is
always composed of three instructions: a prologue instruction, a main
instruction and an epilogue instruction. As an illustration, here are the
implementations of these memory operations in glibc 2.39:
(gdb) disassemble/r
Dump of assembler code for function __memset_mops:
=> 0x0000fffff7e8d780 <+0>: d503201f nop
0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1
0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1
0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1
0x0000fffff7e8d794 <+20>: d65f03c0 ret
End of assembler dump.
(gdb) disassemble/r
Dump of assembler code for function __memcpy_mops:
=> 0x0000fffff7e8c580 <+0>: d503201f nop
0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2!
0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2!
0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2!
0x0000fffff7e8c594 <+20>: d65f03c0 ret
End of assembler dump.
(gdb) disassemble/r
Dump of assembler code for function __memmove_mops:
=> 0x0000fffff7e8d180 <+0>: d503201f nop
0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2!
0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2!
0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2!
0x0000fffff7e8d194 <+20>: d65f03c0 ret
End of assembler dump.
The Arm Architecture Reference Manual says that "the prologue, main, and
epilogue instructions are expected to be run in succession and to appear
consecutively in memory". Therefore this patch disables displaced stepping
on them.
The testcase verifies that MOPS sequences are correctly single-stepped.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
(cherry picked from commit b995344c11)
In commit:
commit 824083f34c
Date: Fri Apr 12 17:47:20 2024 +0100
gdb/doc: use silent-rules.mk in the Makefile
I rewrote the rules for building the man pages. While doing this I
accidentally switched from using MAN2POD5 to MAN2POD1 for generating
the file gdbinit.5.
Restore use of MAN2POD5 where appropriate.
While preparing the new release it was discovered that commit:
commit 824083f34c
Date: Fri Apr 12 17:47:20 2024 +0100
gdb/doc: use silent-rules.mk in the Makefile
was causing problems. Given a release tar file, an attempt to build
and install GDB would give an error like this:
[...]
TEXI2POD gdb.pod
cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
make[5]: *** [Makefile:663: gdb.pod] Error 2
The problem here is how the man pages are built, and how they are
distributed within a release.
Within the development (git) tree, the man page files are not part of
the source tree, these files are built as needed. Within a release
tar file though, the man pages are included. The idea being that a
user can build and install GDB, including getting the man pages,
without having to install the tools needed to generate the man pages.
The man pages are generated in a two step process. First the .texi
file is processed with texi2pod to create a .pod file, then this .pod
file is processed to create the .1 or .5 man file.
Prior to the above commit these two steps were combined into a single
recipe, this meant that when a user performed a build/install from a
release tree all of the dependencies, as well as the final result,
were all present in the source tree, and so nothing needed to be
rebuilt.
However, the above commit split the two steps apart. Now we had a
separate rule for building the .pod files, and the .1/.5 man page
files depended on the relevant .pod file.
As the .pod files are not shipped in a GDB release, this meant that
one of the dependencies of the man page files was now missing. As a
result if a user tried to install from a release tree a rebuild of the
.pod files would be attempted, and if that succeeded then building the
man pages would follow that.
Unfortunately, building the .pod files would fail as the GDBvn.texi
file, though present in the source tree, was not present in the build
tree, which is where it is needed for the .pod file generation to
work.
To fix this, I propose merging the .pod creation and the .1/.5 man
page creation back into a single recipe. Having these two steps split
is probably the "cleaner" solution, but makes it harder for us to
achieve our goal of shipping the prebuilt man page files. I've added
a comment explaining what's going on (such a comment would have
prevented this mistake having been made in the first place).
One possibly weird thing here is that I have left both an
ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S)
recipes. This is 100% not going to break anything, these just print
two different progress messages while executing the recipes, but I'm
not sure if this is considered poor style or not. Maybe we're only
supposed to have a single ECHO_* per recipe?
Anyway, even if this is poor style, I figure it really is just a style
thing. We can tweak this later as needed. Otherwise, this commit
should fix the current issue blocking the next GDB release.
Approved-By: Tom Tromey <tom@tromey.com>
This commit changes the title of the section to refer to the actual
release version number, now that all changes listed are confirmed
to be part of the upcoming GDB 15 release.
Now that the GDB 15 branch has been created,
this commit bumps the version number in gdb/version.in to
15.0.90.DATE-git
For the record, the GDB 15 branch was created
from commit 3a624d9f1c.
2024-05-26 08:57:12 -07:00
49 changed files with 1211 additions and 104 deletions
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
