From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125109 invoked by alias); 19 Oct 2017 20:10:04 -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 125090 invoked by uid 89); 19 Oct 2017 20:10:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=lean, precautions, states 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; Thu, 19 Oct 2017 20:10:03 +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 v9JK9uqp006263 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 19 Oct 2017 16:10:01 -0400 Received: by simark.ca (Postfix, from userid 112) id 8385F1E56A; Thu, 19 Oct 2017 16:09:56 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id E5F0E1E525; Thu, 19 Oct 2017 16:09:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 19 Oct 2017 20:10:00 -0000 From: Simon Marchi To: Mike Gulick Cc: gdb-patches@sourceware.org Subject: Re: [RFC][PATCH] fix gdb segv when objfile can't be opened In-Reply-To: References: <59E8B251.4050100@mathworks.com> <8c08307a-94ad-92b8-9c8b-c713cad541fd@mathworks.com> <56b1cb34b33613ca4496abfcd28f135a@polymtl.ca> Message-ID: <402f0a7a85cc7c3ba1c26cd296d570a1@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.0 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 19 Oct 2017 20:09:56 +0000 X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00644.txt.bz2 On 2017-10-19 15:39, Mike Gulick wrote: > I had trouble figuring out what the 'error' function actually does (I > couldn't find where it was defined). When I'm stepping through GDB in > the debugger, the lines past 'error' never seem to get called. It's > like 'error' throws an exception that is caught elsewhere. Indeed, "error" throws an exception. You should be able at least to step into the error function (although it's not particularly useful nor interesting). It is defined in common/errors.c. > I was also > unable to figure out why the error message isn't displayed. The new > reproducer shows this issue. I wasn't sure if setting *size or even > descriptor->size was the right thing to do, but it seemed reasonable to > me since the comment in gdb_bfd.h states that this function updates > *size. There's currently only one caller for 'gdb_bfd_map_section', so > I have no problem updating *size there if that is preferred. Actually it says "If successful, the section data is returned and *SIZE is set to the size of the section data;". And this is what I would generally expect from functions. Unless stated otherwise, the value of output parameters should be considered undefined if the function failed. So I would lean towards blaming the caller for not taking enough precautions. It trusts that gdb_bfd_map_section won't fail. Simon