Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Patrick Palka <patrick@parcs.ath.cx>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix PR gdb/17820
Date: Tue, 12 May 2015 11:47:00 -0000	[thread overview]
Message-ID: <5551E842.3060706@redhat.com> (raw)
In-Reply-To: <CA+C-WL-A5BhRo0odQz5n3ugVunvgagcD4SWjFn-wF5ZMsHB4cQ@mail.gmail.com>

On 05/12/2015 12:30 PM, Patrick Palka wrote:
> On Wed, Apr 29, 2015 at 6:44 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 04/28/2015 02:05 AM, Patrick Palka wrote:

>>>> 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 for working on this.

Maybe strip -nx out of INTERNAL_GDBFLAGS temporarily.  E.g.,:

 set saved_internal_gdbflags $INTERNAL_GDBFLAGS
 set INTERNAL_GDBFLAGS [string map {"-nx " ""} $INTERNAL_GDBFLAGS]

 ... start gdb here ...

 set INTERNAL_GDBFLAGS $saved_internal_gdbflags

Thanks,
Pedro Alves


  reply	other threads:[~2015-05-12 11:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-26 18:42 Patrick Palka
2015-04-27 18:45 ` Pedro Alves
2015-04-28  1:54   ` Patrick Palka
2015-04-29 12:37     ` Pedro Alves
2015-05-12 11:31       ` Patrick Palka
2015-05-12 11:47         ` Pedro Alves [this message]
2015-05-12 13:07           ` [PATCH] Test the setting of "history size" via $HOME/.gdbinit Patrick Palka
2015-05-12 14:25             ` Pedro Alves
     [not found]               ` <1431479366-18877-1-git-send-email-patrick@parcs.ath.cx>
2015-05-13  9:50                 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5551E842.3060706@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=patrick@parcs.ath.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox