From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97591 invoked by alias); 16 Dec 2018 17:22:55 -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 97570 invoked by uid 89); 16 Dec 2018 17:22:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.4 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_STOCKGEN,SPF_PASS autolearn=ham version=3.3.2 spammy= 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; Sun, 16 Dec 2018 17:22:52 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gYa7s-0002EE-3K for gdb-patches@sourceware.org; Sun, 16 Dec 2018 12:22:51 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYa7r-0002Dt-Um; Sun, 16 Dec 2018 12:22:48 -0500 Received: from [176.228.60.248] (port=4034 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gYa7r-00062V-Ii; Sun, 16 Dec 2018 12:22:47 -0500 Date: Sun, 16 Dec 2018 17:22:00 -0000 Message-Id: <83tvjde68l.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: gdb-patches@sourceware.org In-reply-to: (message from Simon Marchi on Sun, 16 Dec 2018 12:06:07 -0500) Subject: Re: GDB internal error in pc_in_thread_step_range References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> <83a7m6tk92.fsf@gnu.org> <8336qxfpjo.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/msg00189.txt.bz2 > Cc: gdb-patches@sourceware.org > From: Simon Marchi > Date: Sun, 16 Dec 2018 12:06:07 -0500 > > I can't see any mention or even clue that these values would have a special > meaning, it looks to me like they are returned by mistake more than on purpose. If the start address is zero and the length is zero, this is what we will get, right? > > cache_pc_function_low = BMSYMBOL_VALUE_ADDRESS (msymbol); > > cache_pc_function_name = MSYMBOL_LINKAGE_NAME (msymbol.minsym); > > cache_pc_function_section = section; > > cache_pc_function_high = minimal_symbol_upper_bound (msymbol); > > cache_pc_function_block = nullptr; > > > > This is part of find_pc_partial_function. I verified that > > minimal_symbol_upper_bound returns 1 in this case, and that this value > > of 1 is assigned here: > > > > obj_section = MSYMBOL_OBJ_SECTION (minsym.objfile, minsym.minsym); > > if (MSYMBOL_LINKAGE_NAME (msymbol + i) != NULL > > && (MSYMBOL_VALUE_ADDRESS (minsym.objfile, msymbol + i) > > < obj_section_endaddr (obj_section))) > > result = MSYMBOL_VALUE_ADDRESS (minsym.objfile, msymbol + i); <<<<<< > > else > > > > Once again, I'm not an expert on this stuff, but just thinking about > > the situation, what else could GDB return in this case? > > This means that BMSYMBOL_VALUE_ADDRESS (msymbol) returned 0? What is that symbol? Please help me understand what field of which struct do I need to show to answer that question. IOW, when you ask "what is that symbol", what kind of answer do you expect me to provide? > How come by looking up a symbol for PC (what is PC's value, btw) we found this symbol? It comes from this loop, just before the above-mentioned snippet from minimal_symbol_upper_bound: msymbol = minsym.minsym; section = MSYMBOL_SECTION (msymbol); for (i = 1; MSYMBOL_LINKAGE_NAME (msymbol + i) != NULL; i++) { if ((MSYMBOL_VALUE_RAW_ADDRESS (msymbol + i) != MSYMBOL_VALUE_RAW_ADDRESS (msymbol)) && MSYMBOL_SECTION (msymbol + i) == section) break; } > > --- gdb/infrun.c~0 2018-07-04 18:41:59.000000000 +0300 > > +++ gdb/infrun.c 2018-12-16 11:02:24.103425700 +0200 > > @@ -2713,7 +2713,13 @@ resume_1 (enum gdb_signal sig) > > displaced_step_dump_bytes (gdb_stdlog, buf, sizeof (buf)); > > } > > > > - if (tp->control.may_range_step) > > + if (tp->control.may_range_step > > + /* If .step_range_start == 0 and .step_range_end == 1, we don't > > + really know the step range, so don't check in that case. > > + (This is known to happen on MinGW when stepping the program > > + epilogue code after 'main' returns.) */ > > + && !(tp->control.step_range_start == 0x0 > > + && tp->control.step_range_end == 0x1)) > > { > > /* If we're resuming a thread with the PC out of the step > > range, then we're doing some nested/finer run control > > This is treating 0 and 1 as special values, which I don't think they are. It definitely looked to me as if they were special. But I will try to answer your other questions, maybe I was wrong. Thanks.