Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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