This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix PR gdb/17820
- From: Pedro Alves <palves at redhat dot com>
- To: Patrick Palka <patrick at parcs dot ath dot cx>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 12 May 2015 12:47:14 +0100
- Subject: Re: [PATCH] Fix PR gdb/17820
- Authentication-results: sourceware.org; auth=none
- References: <1430073669-31059-1-git-send-email-patrick at parcs dot ath dot cx> <553E826E dot 70300 at redhat dot com> <CA+C-WL952tH-RsK2cFRUVDsCWJZ6EJZi1XuZKRYoYeni8yGkzg at mail dot gmail dot com> <5540B614 dot 8020104 at redhat dot com> <CA+C-WL-A5BhRo0odQz5n3ugVunvgagcD4SWjFn-wF5ZMsHB4cQ at mail dot gmail dot 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