From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89157 invoked by alias); 15 Dec 2018 12:07:51 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 89145 invoked by uid 89); 15 Dec 2018 12:07:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=U*gdb-patches, gdbpatchessourcewareorg, gdb-patches@sourceware.org, infrunc X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 15 Dec 2018 12:07:48 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gY8jL-0000hn-5V for gdb-patches@sourceware.org; Sat, 15 Dec 2018 07:07:44 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gY8jK-0000hb-TB; Sat, 15 Dec 2018 07:07:39 -0500 Received: from [176.228.60.248] (port=2531 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gY8jJ-0005hB-1f; Sat, 15 Dec 2018 07:07:38 -0500 Date: Sat, 15 Dec 2018 12:07:00 -0000 Message-Id: <83a7l7f0xi.fsf@gnu.org> From: Eli Zaretskii To: simon.marchi@polymtl.ca CC: gdb-patches@sourceware.org In-reply-to: <83wool6bu1.fsf@gnu.org> (message from Eli Zaretskii on Fri, 07 Dec 2018 09:21:58 +0200) Subject: Re: GDB internal error in pc_in_thread_step_range References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> <83a7m6tk92.fsf@gnu.org> <83a7lqd6m4.fsf@gnu.org> <83wool6bu1.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00168.txt.bz2 Ping! Ping! Ping! I'd really like to fix this problem for the next GDB release. Can someone please review my findings and suggest a way of solving this? Thanks. > Date: Fri, 07 Dec 2018 09:21:58 +0200 > From: Eli Zaretskii > CC: gdb-patches@sourceware.org > > Ping! Ping! > > I'd really like to fix this problem for the next GDB release. Can > someone please review my findings and suggest a way of solving this? > > Thanks. > > > Date: Fri, 30 Nov 2018 15:42:27 +0200 > > From: Eli Zaretskii > > CC: gdb-patches@sourceware.org > > > > Ping! > > > > > Date: Sun, 18 Nov 2018 18:37:13 +0200 > > > From: Eli Zaretskii > > > CC: gdb-patches@sourceware.org > > > > > > > Date: Mon, 20 Aug 2018 11:08:27 -0400 > > > > From: Simon Marchi > > > > Cc: gdb@sourceware.org > > > > > > A reminder: this is about an internal GDB error that happens on MinGW > > > whenever I step out of the 'main' function. > > > > > > > > Temporary breakpoint 1, main () at hello.c:8 > > > > > 8 printf("hello, world!"); > > > > > (gdb) n > > > > > hello, world!9 return 0; > > > > > (gdb) > > > > > 10 } > > > > > (gdb) > > > > > 0x0040126d in __register_frame_info () > > > > > (gdb) > > > > > Single stepping until exit from function __register_frame_info, > > > > > which has no line number information. > > > > > infrun.c:2728: internal-error: void resume_1(gdb_signal): Assertion > > > > > `pc_in_thread_step_range (pc, tp)' failed. > > > > > A problem internal to GDB has been detected, > > > > > further debugging may prove unreliable. > > > > > Quit this debugging session? (y or n) > > > > > > > > > > Is it a known problem? > > > > > > > > Not that I know of. > > > > > > I finally got to debugging this. It happens because: > > > > > > 2723 gdb_assert (pc_in_thread_step_range (pc, tp)); > > > (top-gdb) p tp->control > > > $22 = {step_resume_breakpoint = 0x0, exception_resume_breakpoint = 0x0, > > > single_step_breakpoints = 0x0, step_range_start = 0x0, > > > step_range_end = 0x1, step_start_function = 0x0, may_range_step = 1, > > > step_frame_id = {stack_addr = 0x28ff70, code_addr = 0x0, > > > special_addr = 0x0, stack_status = FID_STACK_VALID, code_addr_p = 1, > > > special_addr_p = 0, artificial_depth = 0}, step_stack_frame_id = { > > > stack_addr = 0x28ff70, code_addr = 0x0, special_addr = 0x0, > > > stack_status = FID_STACK_VALID, code_addr_p = 1, special_addr_p = 0, > > > artificial_depth = 0}, trap_expected = 0, proceed_to_finish = 0, > > > in_infcall = 0, step_over_calls = STEP_OVER_ALL, stop_step = 0, > > > stop_bpstat = 0x0, stepping_command = 1} > > > > > > The step_range_start is zero and step_range_end is 1, which of course > > > will not match any value of PC. > > > > > > What happens here is that step_1 first zeroes out these members, and > > > then fills them by calling find_pc_line_pc_range, called from > > > prepare_one_step. But when I step out of the main program into the > > > library epilogue code, there's no line information, and > > > prepare_one_step calls find_pc_partial_function, which also doesn't > > > find any addresses. So we fill these members with zero and 1: > > > > > > if (address) > > > { > > > if (pc_in_unmapped_range (pc, section)) > > > *address = overlay_unmapped_address (cache_pc_function_low, section); > > > else > > > *address = cache_pc_function_low; > > > } > > > > > > if (name) > > > *name = cache_pc_function_name; > > > > > > if (endaddr) > > > { > > > if (pc_in_unmapped_range (pc, section)) > > > { > > > /* Because the high address is actually beyond the end of > > > the function (and therefore possibly beyond the end of > > > the overlay), we must actually convert (high - 1) and > > > then add one to that. */ > > > > > > *endaddr = 1 + overlay_unmapped_address (cache_pc_function_high - 1, > > > section); > > > } > > > else > > > *endaddr = cache_pc_function_high; > > > } > > > > > > The cached values are zero and 1, correspondingly. > > > > > > Any suggestions for how to fix this? One way would be to avoid > > > triggering the assertion of the addresses are these two specific bogus > > > values. Alternatively, perhaps the cached values in > > > find_pc_partial_function should be more useful, but in that case I'd > > > need guidance as to where and how are they supposed to be assigned, so > > > that I could look into why they don't in this case. > > > > > > TIA > > > > > >