aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-01-14Automatic date update in version.inGDB Administrator1-1/+1
2021-01-13Automatic date update in version.inGDB Administrator1-1/+1
2021-01-12Automatic date update in version.inGDB Administrator1-1/+1
2021-01-11Automatic date update in version.inGDB Administrator1-1/+1
2021-01-10Automatic date update in version.inGDB Administrator1-1/+1
2021-01-09Automatic date update in version.inGDB Administrator1-1/+1
2021-01-08[gdb] Fix internal-error in process_event_stop_testTom de Vries2-65/+110
The function create_exception_master_breakpoint in gdb/breakpoint.c attempts to set a master exception breakpoint in each objfile. It tries this using a libgcc/unwind probe, and if that fails then using the _Unwind_DebugHook symbol: ... for (objfile *objfile : current_program_space->objfiles ()) { /* Try using probes. */ if (/* successful */) continue; /* Try using _Unwind_DebugHook */ } ... The preference scheme works ok both if the objfile has debug info, and if it's stripped. But it doesn't work when the objfile has a .gnu_debuglink to a .debug file (and the .debug file is present). What happens is that: - we first encounter objfile libgcc.debug - we try using probes, and this fails - so we try _Unwind_DebugHook, which succeeds - next we encounter objfile libgcc - we try using probes, and this succeeds. So, we end up with a master exception breakpoint in both libgcc (using probes) and libgcc.debug (using _Unwind_DebugHook). This eventually causes: ... (gdb) PASS: gdb.cp/nextoverthrow.exp: post-check - next over a throw 3 next^M src/gdb/infrun.c:6384: internal-error: \ void process_event_stop_test(execution_control_state*): \ Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' \ failed.^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M Quit this debugging session? (y or n) FAIL: gdb.cp/nextoverthrow.exp: next past catch (GDB internal error) ... To trigger this internal-error, we need to use gcc-10 or later to compile the test-case, such that it contains the fix for gcc PR97774 - "Incorrect line info for try/catch". Fix this by only trying to install the master exception breakpoint in libgcc.debug using the _Unwind_DebugHook method, if the install using probes in libgcc failed. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-08 Tom de Vries <tdevries@suse.de> PR gdb/26881 * breakpoint.c (create_exception_master_breakpoint_probe) (create_exception_master_breakpoint_hook): Factor out of ... (create_exception_master_breakpoint): ... here. Only try to install the master exception breakpoint in objfile.debug using the _Unwind_DebugHook method, if the install using probes in objfile failed.
2021-01-08Automatic date update in version.inGDB Administrator1-1/+1
2021-01-07[gdb/remote] Fix invalid pointer in remote_async_serial_handlerPedro Alves2-1/+13
On rare occasions, we run into this ERROR/UNRESOLVED on gdb-10-branch: ... (gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 2 Remote debugging from host ::1, port 34088^M Process outputs/gdb.multi/multi-target/multi-target created; pid = 8649^M monitor exit^M (gdb) Killing process(es): 8649^M ERROR: GDB process no longer exists GDB process exited with wait status 8627 exp14 0 0 CHILDKILLED SIGABRT SIGABRT UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5 ... A trigger patch makes the crash happen all the time: ... diff --git a/gdb/remote.c b/gdb/remote.c index 71f814efb365..53ff8b63a1dc 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -14161,14 +14161,12 @@ remote_target::is_async_p () will be able to delay notifying the client of an event until the point where an entire packet has been received. */ -static serial_event_ftype remote_async_serial_handler; - static void remote_async_serial_handler (struct serial *scb, void *context) { - /* Don't propogate error information up to the client. Instead let - the client find out about the error by querying the target. */ - inferior_event_handler (INF_REG_EVENT); + remote_state *rs = (remote_state *) context; + + mark_async_event_handler (rs->remote_async_inferior_event_token); } static void ... And using -fsanitizer=address we can get a more elaborate error message: ... ==7196==ERROR: AddressSanitizer: heap-use-after-free on address \ 0x6170000bf258 at pc 0x000001481755 bp 0x7fff05b20840 sp 0x7fff05b20838 READ of size 8 at 0x6170000bf258 thread T0 #0 0x1481754 in std::_Hashtable<gdbarch*, std::pair<gdbarch* const, remote_arch_state>, std::allocator<std::pair<gdbarch* const, remote_arch_state> >, std::__detail::_Select1st, std::equal_to<gdbarch*>, std::hash<gdbarch*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_bucket_index(unsigned long) const /usr/include/c++/11/bits/hashtable.h:719 #1 0x147c8ab in std::_Hashtable<gdbarch*, std::pair<gdbarch* const, remote_arch_state>, std::allocator<std::pair<gdbarch* const, remote_arch_state> >, std::__detail::_Select1st, std::equal_to<gdbarch*>, std::hash<gdbarch*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::find(gdbarch* const&) /usr/include/c++/11/bits/hashtable.h:1500 #2 0x147852c in std::unordered_map<gdbarch*, remote_arch_state, std::hash<gdbarch*>, std::equal_to<gdbarch*>, std::allocator<std::pair<gdbarch* const, remote_arch_state> > >::find(gdbarch* const&) /usr/include/c++/11/bits/unordered_map.h:869 #3 0x14306db in remote_state::get_remote_arch_state(gdbarch*) src/gdb/remote.c:1203 #4 0x14309dc in remote_target::get_remote_state() src/gdb/remote.c:1232 #5 0x1470c08 in remote_async_inferior_event_handler src/gdb/remote.c:14169 #6 0xaa9f6b in check_async_event_handlers() src/gdb/async-event.c:295 #7 0x1e93ab4 in gdb_do_one_event() src/gdbsupport/event-loop.cc:194 #8 0x118f5f9 in start_event_loop src/gdb/main.c:356 #9 0x118f8ed in captured_command_loop src/gdb/main.c:416 #10 0x1192d6a in captured_main src/gdb/main.c:1253 #11 0x1192dfa in gdb_main(captured_main_args*) src/gdb/main.c:1268 #12 0x97b380 in main src/gdb/gdb.c:32 #13 0x7f550c211349 in __libc_start_main ../csu/libc-start.c:308 #14 0x97b199 in _start (build/gdb/gdb+0x97b199) 0x6170000bf258 is located 600 bytes inside of 648-byte region \ [0x6170000bf000,0x6170000bf288) freed by thread T0 here: #0 0x7f550f516a57 in operator delete(void*, unsigned long) (/usr/lib64/libasan.so.6+0xaea57) #1 0x148b1fe in extended_remote_target::~extended_remote_target() src/gdb/remote.c:958 #2 0x143b483 in remote_target::close() src/gdb/remote.c:4074 #3 0x16cb90f in target_close(target_ops*) src/gdb/target.c:3230 #4 0x16a2635 in decref_target(target_ops*) src/gdb/target.c:557 #5 0x16a2abb in target_stack::unpush(target_ops*) src/gdb/target.c:645 #6 0x16d01ef in inferior::unpush_target(target_ops*) src/gdb/inferior.h:356 #7 0x16a2877 in unpush_target(target_ops*) src/gdb/target.c:607 #8 0x16a2adf in unpush_target_and_assert src/gdb/target.c:655 #9 0x16a2c57 in pop_all_targets_at_and_above(strata) src/gdb/target.c:678 #10 0x1442749 in remote_unpush_target src/gdb/remote.c:5522 #11 0x1458c16 in remote_target::readchar(int) src/gdb/remote.c:9137 #12 0x145b25b in remote_target::getpkt_or_notif_sane_1(std::vector<char, gdb::default_init_allocator<char, std::allocator<char> > >*, int, int, int*) src/gdb/remote.c:9683 #13 0x145bc9a in remote_target::getpkt_sane(std::vector<char, gdb::default_init_allocator<char, std::allocator<char> > >*, int) src/gdb/remote.c:9790 #14 0x145b040 in remote_target::getpkt(std::vector<char, gdb::default_init_allocator<char, std::allocator<char> > >*, int) src/gdb/remote.c:9623 #15 0x145780b in remote_target::remote_read_bytes_1(unsigned long, unsigned char*, unsigned long, int, unsigned long*) src/gdb/remote.c:8860 #16 0x145805e in remote_target::remote_read_bytes(unsigned long, unsigned char*, unsigned long, int, unsigned long*) src/gdb/remote.c:8987 #17 0x146113a in remote_target::xfer_partial(target_object, char const*, unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*) src/gdb/remote.c:10987 #18 0x16a4004 in raw_memory_xfer_partial(target_ops*, unsigned char*, unsigned char const*, unsigned long, long, unsigned long*) src/gdb/target.c:918 #19 0x16a4fcf in target_xfer_partial(target_ops*, target_object, char const*, unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*) src/gdb/target.c:1156 #20 0x16a5d65 in target_read_partial src/gdb/target.c:1387 #21 0x16a5f19 in target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long) src/gdb/target.c:1427 #22 0x16a5666 in target_read_raw_memory(unsigned long, unsigned char*, long) src/gdb/target.c:1260 #23 0xd22f2a in dcache_read_line src/gdb/dcache.c:336 #24 0xd232b7 in dcache_peek_byte src/gdb/dcache.c:403 #25 0xd23845 in dcache_read_memory_partial(target_ops*, dcache_struct*, unsigned long, unsigned char*, unsigned long, unsigned long*) src/gdb/dcache.c:484 #26 0x16a47da in memory_xfer_partial_1 src/gdb/target.c:1041 #27 0x16a4a1e in memory_xfer_partial src/gdb/target.c:1084 #28 0x16a4f44 in target_xfer_partial(target_ops*, target_object, char const*, unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*) src/gdb/target.c:1141 #29 0x18203d4 in read_value_memory(value*, long, int, unsigned long, unsigned char*, unsigned long) src/gdb/valops.c:956 previously allocated by thread T0 here: #0 0x7f550f515c37 in operator new(unsigned long) (/usr/lib64/libasan.so.6+0xadc37) #1 0x14429f0 in remote_target::open_1(char const*, int, int) src/gdb/remote.c:5562 #2 0x14405e6 in extended_remote_target::open(char const*, int) src/gdb/remote.c:4907 #3 0x16a0f3c in open_target src/gdb/target.c:242 #4 0xc19ff5 in do_sfunc src/gdb/cli/cli-decode.c:111 #5 0xc221db in cmd_func(cmd_list_element*, char const*, int) src/gdb/cli/cli-decode.c:2181 #6 0x16feda6 in execute_command(char const*, int) src/gdb/top.c:668 #7 0xee9dc9 in command_handler(char const*) src/gdb/event-top.c:588 #8 0xeea6a8 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) src/gdb/event-top.c:773 #9 0xee8a12 in gdb_rl_callback_handler src/gdb/event-top.c:219 #10 0x7f550f24aead in rl_callback_read_char (/lib64/libreadline.so.7+0x31ead) ... The problem is here in remote_async_inferior_event_handler: ... static void remote_async_inferior_event_handler (gdb_client_data data) { inferior_event_handler (INF_REG_EVENT); remote_target *remote = (remote_target *) data; remote_state *rs = remote->get_remote_state (); ... The remote target (passed in the data argument) can be destroyed during the call to inferior_event_handler. If so, the call to remote->get_remote_state () is done using a dangling pointer. Fix this by increasing the reference count on the remote target before calling inferior_event_handler, such that it won't get destroyed until right before returning from remote_async_inferior_event_handler. Tested on x86_64-linux. Intended for gdb-10-branch. The problem has stopped reproducing with the trigger patch since master commit 79952e69634 "Make scoped_restore_current_thread's cdtors exception free (RFC)". We could still apply this to master though. gdb/ChangeLog: 2021-01-07 Pedro Alves <pedro@palves.net> Simon Marchi <simon.marchi@polymtl.ca> Tom de Vries <tdevries@suse.de> PR remote/26614 * remote.c (remote_async_inferior_event_handler): Hold a strong reference to the remote target while handling an event.
2021-01-07Automatic date update in version.inGDB Administrator1-1/+1
2021-01-06Automatic date update in version.inGDB Administrator1-1/+1
2021-01-05Automatic date update in version.inGDB Administrator1-1/+1
2021-01-04Automatic date update in version.inGDB Administrator1-1/+1
2021-01-03Automatic date update in version.inGDB Administrator1-1/+1
2021-01-02Automatic date update in version.inGDB Administrator1-1/+1
2021-01-01Manual updates of copyright year range not covered by gdb/copyright.pyJoel Brobecker5-5/+13
gdb/ChangeLog: * gdbarch.sh: Update copyright year range. gdb/doc/ChangeLog: * gdb.texinfo, refcard.tex: Update copyright year range. (cherry picked from commit b5b5650a49f326a63fcf79db280f11c01ba7da9f)
2021-01-01Update copyright year range in all GDB filesJoel Brobecker6278-6277/+6281
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2021-01-01gdb/copyright.py: Also update sources in "gdbserver" and "gdbsupport"Joel Brobecker2-1/+8
This commit adjusts GDB's copyright.py script, following two past changes: - gdb/gdbserver/ being move to the toplevel directory; - gdb/common/ being renamed to gdbsupport/. gdb/ChangeLog: * copyright.py (get_update_list): Add "gdbserver" and "gdbsupport" to the list of directories to update. (cherry picked from commit ff7e39b613503fa5d7417e284ee2549117efdb91)
2021-01-01Update copyright year in version message for gdb, gdbserver and gdbreplayJoel Brobecker5-3/+12
gdb/ChangeLog: * top.c (print_gdb_version): Update copyright year. gdbserver/ChangeLog: * server.cc (gdbserver_version): Update copyright year. * gdbreplay.cc (gdbreplay_version): Likewise. (cherry picked from commit 2b47c078fd49164af654744cef9bb8135069199b)
2021-01-01Automatic date update in version.inGDB Administrator1-1/+1
2020-12-31Automatic date update in version.inGDB Administrator1-1/+1
2020-12-30Automatic date update in version.inGDB Administrator1-1/+1
2020-12-29Automatic date update in version.inGDB Administrator1-1/+1
2020-12-28Automatic date update in version.inGDB Administrator1-1/+1
2020-12-27Automatic date update in version.inGDB Administrator1-1/+1
2020-12-26Fix capitalization in the GDB manualJeanne Rasata2-82/+87
gdb/doc/ChangeLog: 2020-12-26 Jeanne Rasata <jeanne@fsf.org> * gdb.texinfo: Fix capitalization in many sections following CMS style-guide rules, remove period at end of a few headings. Copyright-paperwork-exempt: yes
2020-12-26Automatic date update in version.inGDB Administrator1-1/+1
2020-12-25Automatic date update in version.inGDB Administrator1-1/+1
2020-12-24Automatic date update in version.inGDB Administrator1-1/+1
2020-12-23Automatic date update in version.inGDB Administrator1-1/+1
2020-12-22Automatic date update in version.inGDB Administrator1-1/+1
2020-12-21Automatic date update in version.inGDB Administrator1-1/+1
2020-12-20Automatic date update in version.inGDB Administrator1-1/+1
2020-12-19Automatic date update in version.inGDB Administrator1-1/+1
2020-12-18Automatic date update in version.inGDB Administrator1-1/+1
2020-12-17Automatic date update in version.inGDB Administrator1-1/+1
2020-12-16Automatic date update in version.inGDB Administrator1-1/+1
2020-12-15Automatic date update in version.inGDB Administrator1-1/+1
2020-12-14Automatic date update in version.inGDB Administrator1-1/+1
2020-12-13Automatic date update in version.inGDB Administrator1-1/+1
2020-12-12Automatic date update in version.inGDB Administrator1-1/+1
2020-12-11Automatic date update in version.inGDB Administrator1-1/+1
2020-12-10Automatic date update in version.inGDB Administrator1-1/+1
2020-12-09gdb: address review comments of previous seriesSimon Marchi2-6/+15
I forgot to include fixes for review comments I got before pushing the previous commits (or I pushed the wrong commits). This one fixes it. - Return {} instead of false in get_discrete_low_bound and get_discrete_high_bound. - Compute high bound after confirming low bound is valid in get_discrete_bounds. gdb/ChangeLog: * gdbtypes.c (get_discrete_low_bound, get_discrete_high_bound): Return {} instead of false. (get_discrete_bounds): Compute high bound only if low bound is valid. Change-Id: I5f9a66b3672adfac9441068c899ab113ab2c331a
2020-12-09gdb: fix value_subscript when array upper bound is not knownSimon Marchi7-11/+179
Since commit 7c6f27129631 ("gdb: make get_discrete_bounds check for non-constant range bounds"), subscripting flexible array member fails: struct no_size { int n; int items[]; }; (gdb) p *ns $1 = {n = 3, items = 0x5555555592a4} (gdb) p ns->items[0] Cannot access memory at address 0xfffe555b733a0164 (gdb) p *((int *) 0x5555555592a4) $2 = 101 <--- we would expect that (gdb) p &ns->items[0] $3 = (int *) 0xfffe5559ee829a24 <--- wrong address Since the flexible array member (items) has an unspecified size, the array type created for it in the DWARF doesn't have dimensions (this is with gcc 9.3.0, Ubuntu 20.04): 0x000000a4: DW_TAG_array_type DW_AT_type [DW_FORM_ref4] (0x00000038 "int") DW_AT_sibling [DW_FORM_ref4] (0x000000b3) 0x000000ad: DW_TAG_subrange_type DW_AT_type [DW_FORM_ref4] (0x00000031 "long unsigned int") This causes GDB to create a range type (TYPE_CODE_RANGE) with a defined constant low bound (dynamic_prop with kind PROP_CONST) and an undefined high bound (dynamic_prop with kind PROP_UNDEFINED). value_subscript gets both bounds of that range using get_discrete_bounds. Before commit 7c6f27129631, get_discrete_bounds didn't check the kind of the dynamic_props and would just blindly read them as if they were PROP_CONST. It would return 0 for the high bound, because we zero-initialize the range_bounds structure. And it didn't really matter in this case, because the returned high bound wasn't used in the end. Commit 7c6f27129631 changed get_discrete_bounds to return a failure if either the low or high bound is not a constant, to make sure we don't read a dynamic prop that isn't a PROP_CONST as a PROP_CONST. This change made get_discrete_bounds start to return a failure for that range, and as a result would not set *lowp and *highp. And since value_subscript doesn't check get_discrete_bounds' return value, it just carries on an uses an uninitialized value for the low bound. If value_subscript did check the return value of get_discrete_bounds, we would get an error message instead of a bogus value. But it would still be a bug, as we wouldn't be able to print the flexible array member's elements. Looking at value_subscript, we see that the low bound is always needed, but the high bound is only needed if !c_style. So, change value_subscript to use get_discrete_low_bound and get_discrete_high_bound separately. This fixes the case described above, where the low bound is known but the high bound isn't (and is not needed). This restores the original behavior without accessing a dynamic_prop in a wrong way. A test is added. In addition to the case described above, a case with an array member of size 0 is added, which is a GNU C extension that existed before flexible array members were introduced. That case currently fails when compiled with gcc <= 8. gcc <= 8 produces DWARF similar to the one shown above, while gcc 9 adds a DW_AT_count of 0 in there, which makes the high bound known. A case where an array member of size 0 is the only member of the struct is also added, as that was how PR 28675 was originally reported, and it's an interesting corner case that I think could trigger other funny bugs. Question about the implementation: in value_subscript, I made it such that if the low or high bound is unknown, we fall back to zero. That effectively makes it the same as it was before 7c6f27129631. But should we instead error() out? gdb/ChangeLog: PR 26875, PR 26901 * gdbtypes.c (get_discrete_low_bound): Make non-static. (get_discrete_high_bound): Make non-static. * gdbtypes.h (get_discrete_low_bound): New declaration. (get_discrete_high_bound): New declaration. * valarith.c (value_subscript): Only fetch high bound if necessary. gdb/testsuite/ChangeLog: PR 26875, PR 26901 * gdb.base/flexible-array-member.c: New test. * gdb.base/flexible-array-member.exp: New test. Change-Id: I832056f80e6c56f621f398b4780d55a3a1e299d7
2020-12-09gdb: split get_discrete_bounds in twoSimon Marchi2-59/+137
get_discrete_bounds is not flexible for ranges (TYPE_CODE_RANGE), in the sense that it returns true (success) only if both bounds are present and constant values. This is a problem for code that only needs to know the low bound and fails unnecessarily if the high bound is unknown. Split the function in two, get_discrete_low_bound and get_discrete_high_bound, that both return an optional. Provide a new implementation of get_discrete_bounds based on the two others, so the callers don't have to be changed. gdb/ChangeLog: * gdbtypes.c (get_discrete_bounds): Implement with get_discrete_low_bound and get_discrete_high_bound. (get_discrete_low_bound): New. (get_discrete_high_bound): New. Change-Id: I986b5e9c0dd969800e3fb9546af9c827d52e80d0
2020-12-09gdb: make get_discrete_bounds return boolSimon Marchi12-46/+54
get_discrete_bounds currently has three possible return values (see its current doc for details). It appears that for all callers, it would be sufficient to have a boolean "worked" / "didn't work" return value. Change the return type of get_discrete_bounds to bool and adjust all callers. Doing so simplifies the following patch. gdb/ChangeLog: * gdbtypes.h (get_discrete_bounds): Return bool, adjust all callers. * gdbtypes.c (get_discrete_bounds): Return bool. Change-Id: Ie51feee23c75f0cd7939742604282d745db59172
2020-12-09gdb: make discrete_position return optionalSimon Marchi4-25/+47
Instead of returning a boolean status and returning the value through a pointer, return an optional that does both jobs. This helps in the following patches, and I think it is an improvement in general. gdb/ChangeLog: * ada-lang.c (ada_value_slice_from_ptr): Adjust. (ada_value_slice): Adjust. (pos_atr): Adjust. * gdbtypes.c (get_discrete_bounds): Adjust. (discrete_position): Return optional. * gdbtypes.h (discrete_position): Return optional. Change-Id: I758dbd8858b296ee472ed39ec35db1dbd624a5ae
2020-12-09Automatic date update in version.inGDB Administrator1-1/+1
2020-12-08Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2025-09-19 09:48:40 +0000