From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24514 invoked by alias); 24 Jan 2002 07:29:39 -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 24479 invoked from network); 24 Jan 2002 07:29:34 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 24 Jan 2002 07:29:34 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g0O7TYQ05761 for ; Wed, 23 Jan 2002 23:29:34 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 23 Jan 2002 23:29:34 -0800 Received: from apple.com (il0204a-dhcp35.apple.com [17.202.45.163]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g0O7TXw22840; Wed, 23 Jan 2002 23:29:33 -0800 (PST) Message-ID: <3C4FB7DE.2CEB1E10@apple.com> Date: Wed, 23 Jan 2002 23:29:00 -0000 From: Stan Shebs X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] New option "trust-readonly-sections" References: <200201240323.g0O3NI905339@reddwarf.cygnus.com> <20020124004435.A11710@nevyn.them.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00717.txt.bz2 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 :-) ). Stan