From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20992 invoked by alias); 28 Jul 2014 19:54:28 -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 20981 invoked by uid 89); 28 Jul 2014 19:54:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f180.google.com Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 28 Jul 2014 19:54:26 +0000 Received: by mail-vc0-f180.google.com with SMTP id ij19so12006506vcb.39 for ; Mon, 28 Jul 2014 12:54:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wQldEfVo1KyTNdEvceiXU7OH1wYebDImo8G1Lh2Vyzg=; b=mAZiQB1PrshUoi0zbKnFhg9QjKQMV2M7lYQPl/f1OEqj26Ep6RORaod07UvnszHGBO 08W/Y/oWqOUW3jk16sRK8DT9+jZpAJxKu4hxITcYq4u7z2+1QHOrNbqxvkIHtJ/E3342 qOW3iUzibPznHUQNgKbyzJGAHg95u6NZnVA/pt3HSyPqvI3nuRU1beOs2Lp5dt698oQG HXtLLDbZG9edfGjAc/+6vLryZ2OSDOFvhKQVpPBxt3z6Nh+DLDsjeN4ydGeSH0H5ANKO bPcDCheMpp5AdDnPSXiGo5wc8Qxo1VPvN/OeEev47H63BHicjItivqrLYLRYQmvyauCa bjhg== X-Gm-Message-State: ALoCoQk2PImrybIogcIBmMst9+dBBOiI10LDKYJqxb57mARwmu2H0ag53aeUKurly00YH6cu7TPL MIME-Version: 1.0 X-Received: by 10.220.187.134 with SMTP id cw6mr11028595vcb.3.1406577264398; Mon, 28 Jul 2014 12:54:24 -0700 (PDT) Received: by 10.52.28.233 with HTTP; Mon, 28 Jul 2014 12:54:24 -0700 (PDT) In-Reply-To: <20140725085134.GB4812@blade.nx> References: <1406206287-6817-1-git-send-email-gbenson@redhat.com> <1406206287-6817-2-git-send-email-gbenson@redhat.com> <21457.17973.551020.113918@ruffy.mtv.corp.google.com> <20140725085134.GB4812@blade.nx> Date: Mon, 28 Jul 2014 20:16:00 -0000 Message-ID: Subject: Re: [PATCH 1/3 v4] Introduce common/errors.h From: Doug Evans To: Gary Benson Cc: gdb-patches , Pedro Alves , Tom Tromey Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00705.txt.bz2 On Fri, Jul 25, 2014 at 1:51 AM, Gary Benson wrote: > Doug Evans wrote: > [...] >> In the case of malloc_failure, it's not really an *internal* error, > > No--and certainly not by the description of internal_error earlier in > the file. > >> even if in the case of gdb it calls internal_error, though arguably >> it should do something different - it's more of a "fatal". :-) >> Though I'm not suggesting trying to go down that path. :-) > > I spoke with Pedro about this in Cambridge. malloc failure is a funny > one: sometimes it's fatal, other times it's not an issue; it depends > entirely on what the memory you were trying to allocate was for. > >> It might be possible come up with a name other than "fatal" that >> could apply to both gdb and gdbserver so that malloc_failure could >> call it, but no need to try to do that now. > > I don't know if you saw but I removed "fatal" from GDB the other day Indeed, saw that. > (http://tinyurl.com/k6neuwd) so the path is clear to add a "fatal" if > we want one. It would be nice if such a function were smart enough to > work even if called before exceptions and cleanups were set up. It > might be a nice general thing if all error-handling functions worked > that way (error and internal_error could work like gdbserver's "fatal" > if called early.) That might even be a prerequisite to moving > exceptions and cleanups into common code and making gdbserver use > them. > > (I'm not planning to do any of this now, this is just thinking aloud!) No worries!