Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Doug Evans <dje@google.com>, Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Yao Qi <qiyaoltc@gmail.com>, gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC] Unset tcl variable addr to avoid clashing
Date: Mon, 13 Apr 2015 08:26:00 -0000	[thread overview]
Message-ID: <552B7DA3.5070103@redhat.com> (raw)
In-Reply-To: <CADPb22QcfoJqK15FjHSbownWbT-0FpJ3KLQWdOCe7Ud7B_0oAQ@mail.gmail.com>

On 04/12/2015 06:22 PM, Doug Evans wrote:
> On Sat, Apr 11, 2015 at 10:03 AM, Sergio Durigan Junior
> <sergiodj@redhat.com> wrote:
>> On Friday, April 10 2015, Yao Qi wrote:
>>
>>> From: Yao Qi <yao.qi@linaro.org>
>>>
>>> Hi,
>>> I see some tcl ERRORs in gdb.sum recently:
>>>
>>> ERROR: tcl error sourcing ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp.
>>> ERROR: can't set "addr": variable is array
>>>     while executing
>>> "set addr "0x\[0-9a-zA-Z\]+""
>>>     (file "../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp" line 45)
>>>     invoked from within
>>> "source ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp"
>>>     ("uplevel" body line 1)
>>>     invoked from within
>>> "uplevel #0 source ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp"
>>>     invoked from within
>>> "catch "uplevel #0 source $test_file_name""
>>>
>>> It is OK to run single dmsym.exp.  This error is caused by the name
>>> clashing with coredump-filter.exp, and it can be reproduced,
>>
>> It seems that coredump-filter.exp is causing lots of headaches
>> lately...  Sorry about that.
>>
>>>  $ make check RUNTESTFLAGS='coredump-filter.exp dmsym.exp exception.exp stepi-random-signal.exp'
>>>
>>> as variable addr is used in all of them.  This patch is to unset array
>>> addr, but manually unset variables isn't good to me.  Is there any
>>> approaches we can do to avoid name clashing?
>>
>> FWIW, there is not strong reason to keep the variable name as "addr" in
>> the testcase.  So, an easier solution would be to rename the variable to
>> something else, like "coredump_var_addr" (I think this name is unique
>> enough).  The patch below does that.
>>
>> WDYT?
>>
>> --
>> Sergio
>> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
>> Please send encrypted e-mail if possible
>> http://sergiodj.net/
>>
>> gdb/testsuite/ChangeLog:
>> 2015-04-11  Sergio Durigan Junior  <sergiodj@redhat.com>
>>
>>         * gdb.base/coredump-filter.exp: Rename variable "addr" to
>>         "coredump_var_addr" to avoid naming conflict with other
>>         testcases.
> 
> Ok by me with one nit.
> There's an issue here that still needs to be documented so it becomes
> part of the collective lore.
> Can this include a note about the need to give global array variables
> unique names to either testsuite/README or
> https://sourceware.org/gdb/wiki/Internals%20GDB-Testsuite-Coding-Standards

I don't agree with this resolution.  Renaming is not sufficient.

The same .exp file can be run in the same dejagnu invocation.  Most
commonly, RUNTESTFLAGS="--target_board=unix\{-m64,-m32\}",
but can also be mix of native and gdbserver, like
RUNTESTFLAGS="--target_board='unix native-gdbserver'"

So it's not just conflicting with other testcases that we need
to worry about, but also a testcase conflicting with itself.  Even
though in that "multiple boards" scenario the variable will be arrays in
all invocations, we should still clear it to avoid stale
contents, like e.g., here:

  https://sourceware.org/ml/gdb-patches/2015-04/msg00261.html

Therefore I think the solution must be that we unset/clear the
variable.  And if we must do that, then the renaming to avoid
naming conflicts is not a necessary condition.

Thanks,
Pedro Alves


  parent reply	other threads:[~2015-04-13  8:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 11:51 Yao Qi
2015-04-10 16:53 ` Doug Evans
2015-04-10 17:55   ` Keith Seitz
2015-04-10 18:08     ` Doug Evans
2015-04-11 17:03 ` Sergio Durigan Junior
2015-04-12 17:22   ` Doug Evans
2015-04-13  6:47     ` Sergio Durigan Junior
2015-04-13  8:26     ` Pedro Alves [this message]
2015-04-14 19:12       ` Sergio Durigan Junior
2015-04-26 19:44         ` Sergio Durigan Junior

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=552B7DA3.5070103@redhat.com \
    --to=palves@redhat.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    --cc=sergiodj@redhat.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