From: Pedro Alves <pedro@codesourcery.com>
To: "Sérgio Durigan Júnior" <sergiodj@linux.vnet.ibm.com>
Cc: gdb-patches@sourceware.org, Joel Brobecker <brobecker@adacore.com>
Subject: Re: Can we make gdbinit.in set the data-directory to @srcdir@?
Date: Tue, 06 Oct 2009 08:48:00 -0000 [thread overview]
Message-ID: <200910060948.04899.pedro@codesourcery.com> (raw)
In-Reply-To: <200910060144.08110.sergiodj@linux.vnet.ibm.com>
On Tuesday 06 October 2009 05:44:08, Sérgio Durigan Júnior wrote:
> Also, there's one more thing I'd like to point out. The catch syscall
> testcase partially relies in the fact that GDB will not have the data-
> directory automatically set on startup.
The tests run with "gdb -nx", thus garanteed to skip any
.gdbinit file. (I did check that the patch had introduced no
regressions.)
> This is because, among other things,
> it has to test how GDB behaves when it doesn't have access to the XML files
> for the architecture (or even when those files don't exist at all), and this
> scenario is achieved when data-directory is empty.
But, data-directory isn't empty by default.
(gdb) show data-directory
GDB's data directory is "/usr/local/share/gdb".
> Anyway, if we decide to make this parameter be automatically set upon GDB's
> initialization in the build dir, we have to make sure that this doesn't break
> the testcase (I didn't test this specific case yet, but IIRC it's likely that
> it will break). If it does, we may need to unset it on some situations inside
> the testcase in order to make it work properly.
Oh, the test is broken if the default system data-directory
_does_ have contents in it, from a previous installation. Easy to test. See:
Using the default /usr/local/ prefix, no gdb installed yet:
$ make check RUNTESTFLAGS="catch-syscall.exp"
...
# of expected passes 45
$ sudo make install
... yadda, yadda ...
$ make check RUNTESTFLAGS="catch-syscall.exp"
Running ../../../src/gdb/testsuite/gdb.base/catch-syscall.exp ...
FAIL: gdb.base/catch-syscall.exp: Catch syscall displays a warning when there is no XML support
FAIL: gdb.base/catch-syscall.exp: catch syscall with arguments (3)
FAIL: gdb.base/catch-syscall.exp: syscall(s) 3 appears in 'info breakpoints'
FAIL: gdb.base/catch-syscall.exp: program has called 3
FAIL: gdb.base/catch-syscall.exp: syscall 3 has returned
--
Pedro Alves
next prev parent reply other threads:[~2009-10-06 8:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 19:56 Pedro Alves
2009-10-02 21:05 ` Joel Brobecker
2009-10-04 13:55 ` Pedro Alves
2009-10-05 13:41 ` Pedro Alves
2009-10-06 4:44 ` Sérgio Durigan Júnior
2009-10-06 5:34 ` Doug Evans
2009-10-06 9:33 ` Pedro Alves
2009-10-06 8:48 ` Pedro Alves [this message]
2009-11-22 23:00 ` Make sure catch-syscall.exp doesn't pick up system/installed syscalls xml 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=200910060948.04899.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=sergiodj@linux.vnet.ibm.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