aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-27Set GDB version number to 13.2.gdb-13.2-releaseJoel Brobecker1-1/+1
This commit changes gdb/version.in to 13.2.
2023-05-27Automatic date update in version.inGDB Administrator1-1/+1
2023-05-26Automatic date update in version.inGDB Administrator1-1/+1
2023-05-25Automatic date update in version.inGDB Administrator1-1/+1
2023-05-24Automatic date update in version.inGDB Administrator1-1/+1
2023-05-23Automatic date update in version.inGDB Administrator1-1/+1
2023-05-22Automatic date update in version.inGDB Administrator1-1/+1
2023-05-21Automatic date update in version.inGDB Administrator1-1/+1
2023-05-20gdb: fix post-hook execution for remote targetsJan Vrany1-1/+3
Commit b5661ff2 ("gdb: fix possible use-after-free when executing commands") attempted to fix possible use-after-free in case command redefines itself. Commit 37e5833d ("gdb: fix command lookup in execute_command ()") updated the previous fix to handle subcommands as well by using the original command string to lookup the command again after its execution. This fixed the test in gdb.base/define.exp but it turned out that it does not work (at least) for "target remote" and "target extended-remote". The problem is that the command buffer P passed to execute_command () gets overwritten in dont_repeat () while executing "target remote" command itself: #0 dont_repeat () at top.c:822 #1 0x000055555730982a in target_preopen (from_tty=1) at target.c:2483 #2 0x000055555711e911 in remote_target::open_1 (name=0x55555881c7fe ":1234", from_tty=1, extended_p=0) at remote.c:5946 #3 0x000055555711d577 in remote_target::open (name=0x55555881c7fe ":1234", from_tty=1) at remote.c:5272 #4 0x00005555573062f2 in open_target (args=0x55555881c7fe ":1234", from_tty=1, command=0x5555589d0490) at target.c:853 #5 0x0000555556ad22fa in cmd_func (cmd=0x5555589d0490, args=0x55555881c7fe ":1234", from_tty=1) at cli/cli-decode.c:2737 #6 0x00005555573487fd in execute_command (p=0x55555881c802 "4", from_tty=1) at top.c:688 Therefore the second call to lookup_cmd () at line 697 fails to find command because the original command string is gone. This commit addresses this particular problem by creating a *copy* of original command string for the sole purpose of using it after command execution to lookup the command again. It may not be the most efficient way but it's safer given that command buffer is shared and overwritten in hard-to-foresee situations. Tested on x86_64-linux. PR 30249 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30249 Approved-By: Tom Tromey <tom@tromey.com> (cherry picked from commit b69378ced6a2db6adfbea9974a246a65d931bab2)
2023-05-20Automatic date update in version.inGDB Administrator1-1/+1
2023-05-19Automatic date update in version.inGDB Administrator1-1/+1
2023-05-18Automatic date update in version.inGDB Administrator1-1/+1
2023-05-17Automatic date update in version.inGDB Administrator1-1/+1
2023-05-16gdbserver/linux-low.cc: Fix a typo in ternary operatorKhem Raj1-1/+1
Signed-off-by: Khem Raj <raj.khem@gmail.com> (cherry picked from commit 2e977d9901393ea1bacbe1896af0929e968bc811) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30450
2023-05-16Automatic date update in version.inGDB Administrator1-1/+1
2023-05-15Correctly handle forward DIE references in scannerTom Tromey2-3/+106
The cooked index scanner has special code to handle forward DIE references. However, a bug report lead to the discovery that this code does not work -- the "deferred_entry::spec_offset" field is written to but never used, i.e., the lookup is done using the wrong key. This patch fixes the bug and adds a regression test. The test in the bug itself used a thread_local variable, which provoked a failure at runtime. This test instead uses "maint print objfiles" and then inspects to ensure that the entry in question has a parent. This lets us avoid a clang dependency in the test. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30271 (cherry picked from commit b10f2cd3f3c3b25c71e50a342fb46f9eb9eba792)
2023-05-15Automatic date update in version.inGDB Administrator1-1/+1
2023-05-14Automatic date update in version.inGDB Administrator1-1/+1
2023-05-13Automatic date update in version.inGDB Administrator1-1/+1
2023-05-12Automatic date update in version.inGDB Administrator1-1/+1
2023-05-11Automatic date update in version.inGDB Administrator1-1/+1
2023-05-10Automatic date update in version.inGDB Administrator1-1/+1
2023-05-09Automatic date update in version.inGDB Administrator1-1/+1
2023-05-08Automatic date update in version.inGDB Administrator1-1/+1
2023-05-07Automatic date update in version.inGDB Administrator1-1/+1
2023-05-06Automatic date update in version.inGDB Administrator1-1/+1
2023-05-05gdb: fix -Wsingle-bit-bitfield-constant-conversion warning in z80-tdep.cSimon Marchi1-5/+5
When building with clang 16, I see: /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:338:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] info->prologue_type.load_args = 1; ^ ~ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:345:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] info->prologue_type.critical = 1; ^ ~ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:351:37: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] info->prologue_type.interrupt = 1; ^ ~ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:367:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] info->prologue_type.fp_sdcc = 1; ^ ~ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:375:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] info->prologue_type.fp_sdcc = 1; ^ ~ /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:380:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] info->prologue_type.fp_sdcc = 1; ^ ~ Fix that by using "unsigned int" as the bitfield's underlying type. (cherry picked from commit 07f285934886016ddd82cac99a3873e68b499d5c) Change-Id: I3550a0112f993865dc70b18f02ab11bb5012693d Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30423 Approved-By: Tom Tromey <tom@tromey.com>
2023-05-05gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.hSimon Marchi2-0/+12
When building with clang 16, we get: CXX gdb.o In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19: In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65: /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion] integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type ^ The error message does not make it clear in the context of which enum flag this fails (i.e. what is T in this context), but it doesn't really matter, we have similar warning/errors for many of them, if we let the build go through. clang is right that the value -1 is invalid for the enum type we cast -1 to. However, we do need this expression in order to select an integer type with the appropriate signedness. That is, with the same signedness as the underlying type of the enum. I first wondered if that was really needed, if we couldn't use std::underlying_type for that. It turns out that the comment just above says: /* Note that std::underlying_type<enum_type> is not what we want here, since that returns unsigned int even when the enum decays to signed int. */ I was surprised, because std::is_signed<std::underlying_type<enum_type>> returns the right thing. So I tried replacing all this with std::underlying_type, see if that would work. Doing so causes some build failures in unittests/enum-flags-selftests.c: CXX unittests/enum-flags-selftests.o /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same<selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<s elftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selftests::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_fla gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<selftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selfte sts::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_flags_tests::URE, unsigned int>>::value == true': CHECK_VALID (true, int, true ? EF () : EF2 ()) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID' CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6' CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2, \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT' static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>, \ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a bit hard to decode, but basically enumerations have the following funny property that they decay into a signed int, even if their implicit underlying type is unsigned. This code: enum A {}; enum B {}; int main() { std::cout << std::is_signed<std::underlying_type<A>::type>::value << std::endl; std::cout << std::is_signed<std::underlying_type<B>::type>::value << std::endl; auto result = true ? A() : B(); std::cout << std::is_signed<decltype(result)>::value << std::endl; } produces: 0 0 1 So, the "CHECK_VALID" above checks that this property works for enum flags the same way as it would if you were using their underlying enum types. And somehow, changing integer_for_size to use std::underlying_type breaks that. Since the current code does what we want, and I don't see any way of doing it differently, ignore -Wenum-constexpr-conversion around it. (cherry picked from commit ae61525fcf456ab395d55c45492a106d1275873a) Change-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30423 Approved-By: Tom Tromey <tom@tromey.com>
2023-05-05Automatic date update in version.inGDB Administrator1-1/+1
2023-05-04Automatic date update in version.inGDB Administrator1-1/+1
2023-05-03Automatic date update in version.inGDB Administrator1-1/+1
2023-05-02Automatic date update in version.inGDB Administrator1-1/+1
2023-05-01Automatic date update in version.inGDB Administrator1-1/+1
2023-04-30Automatic date update in version.inGDB Administrator1-1/+1
2023-04-29Automatic date update in version.inGDB Administrator1-1/+1
2023-04-28Automatic date update in version.inGDB Administrator1-1/+1
2023-04-27Automatic date update in version.inGDB Administrator1-1/+1
2023-04-26Automatic date update in version.inGDB Administrator1-1/+1
2023-04-25Automatic date update in version.inGDB Administrator1-1/+1
2023-04-24Automatic date update in version.inGDB Administrator1-1/+1
2023-04-23Automatic date update in version.inGDB Administrator1-1/+1
2023-04-22gdb: Fix false match issue in skip_prologue_using_linetableWANG Rui3-1/+151
[ Changes in v2: - rebase on trunk Changes in v3: - add test-case ] We should exclude matches to the ending PC to prevent false matches with the next function, as prologue_end is located at the end PC. <fun1>: 0x00: ... <-- start_pc 0x04: ... 0x08: ... <-- breakpoint 0x0c: ret <fun2>: 0x10: ret <-- end_pc | prologue_end of fun2 Tested on x86_64-linux. Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1]) Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case) Approved-by: Kevin Buettner <kevinb@redhat.com> [1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html PR symtab/30369 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369
2023-04-22Automatic date update in version.inGDB Administrator1-1/+1
2023-04-21Automatic date update in version.inGDB Administrator1-1/+1
2023-04-20Automatic date update in version.inGDB Administrator1-1/+1
2023-04-19Automatic date update in version.inGDB Administrator1-1/+1
2023-04-18[gdb/symtab] Handle empty file name in .debug_line sectionTom de Vries2-0/+74
With DWARF 5, it's possible to produce an empty file name in the File Name Table of the .debug_line section: ... The File Name Table (offset 0x112, lines 1, columns 2): Entry Dir Name 0 1 (indirect line string, offset: 0x2d): ... Currently, when gdb reads an exec containing such debug info, it segfaults: ... Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \ gdb/dwarf2/read.c:18716 18716 if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL) ... because read_direct_string transforms "" into a nullptr, and we end up dereferencing the nullptr. Note that the behaviour of read_direct_string has been present since repo creation. Fix this in read_formatted_entries, by transforming nullptr filenames in to "" filenames. Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com> PR symtab/30357 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357
2023-04-18Automatic date update in version.inGDB Administrator1-1/+1
2023-04-17Automatic date update in version.inGDB Administrator1-1/+1
2023-04-16Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2024-07-17 22:30:57 +0000