From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23075 invoked by alias); 16 Dec 2018 17:06:20 -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 23065 invoked by uid 89); 16 Dec 2018 17:06:20 -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_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=dig X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 16 Dec 2018 17:06:18 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id wBGH687B001470 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Dec 2018 12:06:13 -0500 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id D9D1E1E4C2; Sun, 16 Dec 2018 12:06:07 -0500 (EST) Subject: Re: GDB internal error in pc_in_thread_step_range To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> <83a7m6tk92.fsf@gnu.org> <8336qxfpjo.fsf@gnu.org> From: Simon Marchi Message-ID: Date: Sun, 16 Dec 2018 17:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <8336qxfpjo.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00188.txt.bz2 On 2018-12-16 10:40 a.m., Eli Zaretskii wrote: > What else can we expect from a code at PC for which there's absolutely > no symbolic information? So yes, I think it's reasonable, but I'm far > from being an expert on these parts of GDB. 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. >> They are supposed to hold a range of program addresses, so 0 and 1 >> seem bogus. Maybe this is the result of something going wrong >> before? It would be interesting to understand how they end up with >> these values. > > They are assigned here: > > 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? How come by looking up a symbol for PC (what is PC's value, btw) we found this symbol? >> If find_pc_partial_function is unable to determine a proper symbol and some proper >> bounds, it should return 0. So if it returns 1 but returns some wrong data, >> something is fishy. > > If it returns zero, we will emit an error message: > > if (find_pc_partial_function (pc, &name, > &tp->control.step_range_start, > &tp->control.step_range_end) == 0) > error (_("Cannot find bounds of current function")); > > So I'm not sure this is a good idea. That sounds like a reasonable thing to happen if the user tries to use "step" and we are not able to compute the function bounds. The question is, are we really unable to compute the function bounds, or are able, we are just messing it up. The goal of find_pc_partial_function's ADDRESS and ENDADDR out parameters is to give the range of the function PC is in. If find_pc_partial_function returns "success" but [ADDRESS,ENDADDR[ does not enclose PC, that really sounds like a bug to me, and this is where I'd dig. Instead, I propose the following > change: > > --- 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. Simon