From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7845 invoked by alias); 1 Feb 2010 06:54:02 -0000 Received: (qmail 7837 invoked by uid 22791); 1 Feb 2010 06:54:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Feb 2010 06:53:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8E19F2BAB58; Mon, 1 Feb 2010 01:53:55 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GoTbY66De1ch; Mon, 1 Feb 2010 01:53:55 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C86CC2BAB50; Mon, 1 Feb 2010 01:53:54 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 05653F59A0; Mon, 1 Feb 2010 10:53:28 +0400 (RET) Date: Mon, 01 Feb 2010 06:54:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [RFC/ia64] memory error when reading wrong core file Message-ID: <20100201065327.GM26827@adacore.com> References: <20100129160222.GL26811@adacore.com> <20100201012458.GB6015@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Ycz6tD7Th1CMF4v7" Content-Disposition: inline In-Reply-To: <20100201012458.GB6015@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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 X-SW-Source: 2010-02/txt/msg00002.txt.bz2 --Ycz6tD7Th1CMF4v7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1876 Thanks for taking the time to test my patch! > this specific problem gets also fixed by: > [patch] Sanity check PIE displacement (like the PIC one) > http://sourceware.org/ml/gdb-patches/2010-02/msg00000.html [...] > Still I think you have found a problem of its own which should be fixed > anyway. Agreed. > When some memory access fails it should be IMO printed as it is some sort of > incorrect operation. Therefore I would prefer the attached patch producing: Agreed as well. > Just if there exists catch_errors shouldn't it be used instead of TRY_CATCH? TRY_CATCH was introduced after catch_error, and I *think* that it was intended as a simpler way to call some code while being able to handle gdb exceptions. I don't know about others, but I do not really like the catch_errors/catch_exceptions interface - I think it's awkward to use: You almost always have to define an "args" struct type that contains the arguments, and most of the time a developer will also separate the stub (the function called by catch_exceptions which unmarshalls the function arguments) from the real implementation. TRY_CATCH greatly simplifies the use process, which is why I'm trying to use it in preference to catch errors as much as I can. The downside, as you are pointing out, is the lack of error message when an exception is raised. The attached patch fixes this. That made me wonder, however, why we have 2 routines to do the exception printing. There's probably some cleanup we could do, there... gdb/ChangeLog: * solib-svr4.c (solib_svr4_r_map): catch and print all exception errors while reading the inferior memory, and return zero if an exception was raised. This patch should be strictly equivalent to yours, I believe. I've tested it against the testcase described in this thread as well as the rest of AdaCore's testsuite. -- Joel --Ycz6tD7Th1CMF4v7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="solib-svr4.diff" Content-length: 781 diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c index e497364..dc9a685 100644 --- a/gdb/solib-svr4.c +++ b/gdb/solib-svr4.c @@ -835,9 +835,16 @@ solib_svr4_r_map (struct svr4_info *info) { struct link_map_offsets *lmo = svr4_fetch_link_map_offsets (); struct type *ptr_type = builtin_type (target_gdbarch)->builtin_data_ptr; + CORE_ADDR addr = 0; + volatile struct gdb_exception ex; - return read_memory_typed_address (info->debug_base + lmo->r_map_offset, - ptr_type); + TRY_CATCH (ex, RETURN_MASK_ERROR) + { + addr = read_memory_typed_address (info->debug_base + lmo->r_map_offset, + ptr_type); + } + exception_print (gdb_stderr, ex); + return addr; } /* Find r_brk from the inferior's debug base. */ --Ycz6tD7Th1CMF4v7--