From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15677 invoked by alias); 10 Jun 2004 02:20:52 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15628 invoked from network); 10 Jun 2004 02:20:50 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 10 Jun 2004 02:20:50 -0000 Received: (qmail 26800 invoked by uid 10); 10 Jun 2004 02:20:45 -0000 Received: (qmail 19416 invoked by uid 500); 10 Jun 2004 02:20:37 -0000 From: Ian Lance Taylor To: Steven Johnson Cc: gdb@sources.redhat.com Subject: Re: GDB and ARM Frame Pointer strangeness References: <40C42C75.5020208@neurizon.net> <40C53F70.8030101@neurizon.net> <20040608042936.GA7514@nevyn.them.org> <40C54834.4080408@neurizon.net> <20040608122635.35BD37907B@deneb.localdomain> <40C65020.7010904@neurizon.net> <40C7292E.5040906@gnu.org> <40C79F44.6050006@neurizon.net> Date: Thu, 10 Jun 2004 02:20:00 -0000 In-Reply-To: <40C79F44.6050006@neurizon.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-06/txt/msg00087.txt.bz2 Steven Johnson writes: > 3. It is a pipe dream to say "all stubs should be immune to bad memory > reads" its certainly an ideal goal, but unfortuantely it can not > always be achieved. Let's get concrete about this one. Why can this not always be achieved? Every stub that I've ever worked with achieves it. For example, let's look at gdb/i386-stub.c, which is a sample stub for the i386. This stub presumes the existence of an external function exceptionHandler which causes a specified function to be a trap handler for a specifed exception. For, e.g., exception 13, the stub installs a trap handler which, among other things, calls the macro CHECK_FAULT. That macro checks whether the global variable _mem_fault_routine is non-zero. If it is, the exception handler calls it in a somewhat tricky fashion, and then returns from the exception. When the stub is asked to read from a memory location, it sets _mem_fault_routine to set_mem_err. The set_mem_err function just sets the global variable mem_err to 1. The effect is that if the read from memory is from an invalid address, the function set_mem_err is called, and the program continue running. After the memory is fetched, the code checks mem_err. If mem_err is set, the memory address was invalid, and the stub indicates that to the caller. That is a concrete example of how a common stub handles this issue. That general approach is used by every stub I've worked with. Every processor must give you some mechanism to trap invalid memory addresses. If it doesn't, many things become impossible. If we want to continue this discussion, please explain why your stub can not do something similar. Ian