From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9334 invoked by alias); 24 Jan 2002 18:40:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9302 invoked from network); 24 Jan 2002 18:40:52 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 24 Jan 2002 18:40:52 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA02264; Thu, 24 Jan 2002 10:40:35 -0800 (PST) Message-ID: <3C5053B2.E33C98BA@redhat.com> Date: Thu, 24 Jan 2002 10:40:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Stan Shebs CC: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFA] New option "trust-readonly-sections" References: <200201240323.g0O3NI905339@reddwarf.cygnus.com> <20020124004435.A11710@nevyn.them.org> <3C4FB7DE.2CEB1E10@apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00729.txt.bz2 Stan Shebs wrote: > > Daniel Jacobowitz wrote: > > > > On Wed, Jan 23, 2002 at 07:23:18PM -0800, Michael Snyder wrote: > > > > > > [...] > > > > > > > > I'd rather see this default to on. If you give GDB a binary, it's > > reasonable that GDB read from it - I though it did in a lot of cases, > > but maybe I was mistaken. > > This is not the first time that someone has tried their hand at > pruning target reads - Steve Chamberlain introduced a data > cache for instance. > > Hard experience tells us that this is not something you want to > default to be on. The problem is that most cross-debugging is > to non-memory-protected systems, which means that the supposedly > inviolate text section may very well be scribbled on by an > errant program. In fact, since the program is buggy (that's > why you're using the debugger, right? :-) ), there is a very > good chance that the program is going to be modified without > you realizing it. And that is *really* confusing - I experienced > this myself, and it's most peculiar to have a display/i $pc on, > be si'ing along, and have the effect of each step be quite > different from what the displayed instructions are telling > you should be happening. > > For a flag like this, by defaulting to off, we lessen the > chance of unpleasant surprises for newer users, while the > more experienced risk-takers can turn it on in .gdbinit > and not think about it again (or at least until they get hosed > by the optimization :-) ). I agree with Stan -- I'd rather start out by being conservative. What if we accept the conservative change for now, and then if somebody wants to they can look into adding a further enhanced interface allowing specific back-ends to change the default to "on" if they wish?