From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110531 invoked by alias); 12 May 2015 11:31:14 -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 110475 invoked by uid 89); 12 May 2015 11:31:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-ob0-f181.google.com Received: from mail-ob0-f181.google.com (HELO mail-ob0-f181.google.com) (209.85.214.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 12 May 2015 11:31:13 +0000 Received: by obfe9 with SMTP id e9so2934984obf.1 for ; Tue, 12 May 2015 04:31:11 -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:from:date :message-id:subject:to:cc:content-type; bh=RLXETtsxe4ZOJVsYAp8rD/4ug0VC6QujX1Nk5LRJj1I=; b=FZnWxPZabPuxMN0r5yUR2evDzhlWIFOH4pTu5oz7pCZPoOEnpl9JuH/TzS9pCvW7FG E+ku7pqhaLplWvdA14fvyy7MTMi3ihC7WjLSeM45abf8wtxRtT6FwOuBvhau+RWZzwly 7Dz9INYOtlDzcu4Rw1csSSO/SScy5LvhMrdkUDPov/Ln9NKAboaUBvU7WBJq52JN1GCN hqdp3o7/dcmo+tGq517xd2824NKmsWbYYMKNvHKvSNeWBKiPpjZ+9CYhR4G/R0jqO602 M4lgaVF1Jrb4s4zzAbiZdEg5S7SZW5N9j6+WLpZHFBKWjRbzx66u8bdy8zm9yONJngfE TDSA== X-Gm-Message-State: ALoCoQnl4kDAZDuE2OwEDTIuJS/lW0lsV+wNB93Wd753gU5rRVsCY8aEXiB5bGM9NRCqUVrtTONh X-Received: by 10.202.93.4 with SMTP id r4mr11202874oib.92.1431430270970; Tue, 12 May 2015 04:31:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.243.232 with HTTP; Tue, 12 May 2015 04:30:50 -0700 (PDT) In-Reply-To: <5540B614.8020104@redhat.com> References: <1430073669-31059-1-git-send-email-patrick@parcs.ath.cx> <553E826E.70300@redhat.com> <5540B614.8020104@redhat.com> From: Patrick Palka Date: Tue, 12 May 2015 11:31:00 -0000 Message-ID: Subject: Re: [PATCH] Fix PR gdb/17820 To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-05/txt/msg00269.txt.bz2 On Wed, Apr 29, 2015 at 6:44 AM, Pedro Alves wrote: > On 04/28/2015 02:05 AM, Patrick Palka wrote: >> On Mon, Apr 27, 2015 at 2:39 PM, Pedro Alves wrote: > >>> But now we see that "set history size unlimited" in .gdbinit never >>> really worked. Bummer. So this means that users must have kept >>> using "set history size 0" instead... >> >> "set history size 0" (in the .gdbinit) doesn't set history to >> unlimited either -- it sets it to 256! So users currently have no >> choice but to use "set history size BIGINT" for >> approximately-unlimited history. > > Indeed, looks like that has already been the case... > >>> So if we change this now, there's no way to have a single >>> "set history size FOO" setting that means unlimited with >>> both gdb <= 7.9 and the next gdb release. :-/ Oh well. Maybe we should >>> just tell users to do "set history size BIGINT" instead? >> >> But currently, neither "set history size 0" nor "set history size >> unlimited" mean unlimited (in the .gdbinit). So users today cannot >> set an unlimited history size at all. Changing this now will now at >> least make "set history size unlimited". So whether or not we change >> this now, there will be no way to have a single "set history size FOO" >> setting that means unlimited across current and future GDB versions. >> Am I misunderstanding? >> >>> >>> I'd definitely like to make "set history size 0" really >>> disable history. >>> >>> So I think that if goes forward, it'd be good to have a NEWS entry. >> >> I can think of two things to mention. One is that "set history size >> 0" now really disables history. The other is that "set history size >> unlimited" now really does not truncate history. Do you have anything >> else in mind? > > That's good. Maybe add the suggestion to > use "set history size BIGINT" in .gdbinit, if compatibility > with previous releases is desired. > >>>> PR gdb/17820 >>>> * top.c (history_size_setshow_var): Change type to signed. >>>> Initialize to -2. Update documentation. >>>> (set_readline_history_size): Define. >>>> (set_history_size_command): Use it. Remove logic for handling >>>> out-of-range sizes. >>>> (init_history): Use set_readline_history_size(). Test for a >>>> value of -2 instead of 0 when determining whether to set a >>>> default history size. >>>> (init_main): Decode the argument of the "size" command as a >>>> zuinteger_unlimited. >>> >>> Looks good to me. >>> >>> Adding a testcase would be ideal, but I'll not make it a requirement. >>> I think we should be able to write one making use of GDBFLAGSs. (and >>> IWBN to test the GDBHISTSIZE/HISTSIZE environment variables too, which >>> we can do with "set env(HISTSIZE)", etc.) >> >> Do you have in mind a test that creates a dummy .gdbinit file to be >> read by GDB? Or is there another way to test this code path? > > It may be testable with -x or -ix on the command line too, not > sure, gdb.base/bp-cmds-execution-x-script.exp is an example, though > given "set history size" already behaves different today depending on when > it is called, an alternate way to test the issue that happens to use > the same path today may change in the future, and we may (re)introducing > unnoticed bugs. So I think we should test that path exactly. I was > thinking of creating a dir, put a test .gdbinit file there, and point > HOME at that dir. We'd just skip the test on remote host testing. I tried this but the problem is that the testsuite seems to always pass -nx to invocations of GDB meaning that .gdbinit files are not read. Would you know how to work around this? > > Thanks, > Pedro Alves >