From: Doug Evans <dje@google.com>
To: Michael Snyder <msnyder@vmware.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patch] gdb.exp (INTERNAL_GDBFLAGS): Don't override value provided by user.
Date: Thu, 04 Feb 2010 00:44:00 -0000 [thread overview]
Message-ID: <e394668d1002031644l455abfc7m99a6b80d8fb0e689@mail.gmail.com> (raw)
In-Reply-To: <4B6A16F1.7050405@vmware.com>
On Wed, Feb 3, 2010 at 4:38 PM, Michael Snyder <msnyder@vmware.com> wrote:
> Doug Evans wrote:
>>
>> Hi.
>>
>> I will check this in tomorrow if there are no objections.
>
> How will this affect me?
Previously INTERNAL_GDBFLAGS was always set to "-nw -nx". With the
patch it is only set to that if it hasn't already been set (e.g. by
the user when starting dejagnu, e.g. with make check
RUNTESTFLAGS=INTERNAL_GDBFLAGS=mumble). I'd expect therefore that no
one is currently running dejagnu and setting INTERNAL_GDBFLAGS.
Therefore it shouldn't affect you.
>> It is useful to run the testsuite on the installed gdb.
>> e.g. make check RUNTESTFLAGS=GDB=/usr/bin/gdb
>>
>> When testing the installed gdb one would like to test exactly what the
>> user runs. For environments that have a system.gdbinit (gdb was
>> configured
>> with --with-system-gdbinit) that means using the installed system.gdbinit
>> and not anything from the source/build tree.
>> In order to do this one either needs to not pass "-nx" when dejagnu starts
>> gdb
>> or pass "-x /path/to/system.gdbinit" in addition to -nx.
>> I like the former as it's closer to what the user does.
>>
>> There is also the issue of not loading ~/.gdbinit when running the
>> testsuite, but can be solved by pointing $HOME at a directory without
>> a .gdbinit when running the testsuite.
>>
>> [-nx also skips loading of $pwd/.gdbinit, but the testsuite build
>> directory
>> generally doesn't have one and that's good enough for me for now]
>>
>> 2010-02-03 Doug Evans <dje@google.com>
>>
>> * gdb.exp (INTERNAL_GDBFLAGS): Don't override value provided by
>> user.
>>
>> Index: gdb.exp
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
>> retrieving revision 1.135
>> diff -u -p -r1.135 gdb.exp
>> --- gdb.exp 14 Jan 2010 21:12:00 -0000 1.135
>> +++ gdb.exp 4 Feb 2010 00:15:25 -0000
>> @@ -54,7 +54,10 @@ if ![info exists GDBFLAGS] {
>> verbose "using GDBFLAGS = $GDBFLAGS" 2
>> # INTERNAL_GDBFLAGS contains flags that the testsuite requires.
>> -set INTERNAL_GDBFLAGS "-nw -nx"
>> +global INTERNAL_GDBFLAGS
>> +if ![info exists INTERNAL_GDBFLAGS] {
>> + set INTERNAL_GDBFLAGS "-nw -nx"
>> +}
>> # The variable gdb_prompt is a regexp which matches the gdb prompt.
>> # Set it if it is not already set.
>
>
next prev parent reply other threads:[~2010-02-04 0:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 0:25 Doug Evans
2010-02-04 0:38 ` Michael Snyder
2010-02-04 0:44 ` Doug Evans [this message]
2010-02-04 15:49 ` Tom Tromey
2010-02-05 19:26 ` Doug Evans
2010-02-05 21:43 ` Eli Zaretskii
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=e394668d1002031644l455abfc7m99a6b80d8fb0e689@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=msnyder@vmware.com \
/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