Can we make gdbinit.in set the data-directory to @srcdir@?

Can we make gdbinit.in set the data-directory to @srcdir@?

[Pedro Alves]

While working on "catch syscall" issues, I found it weird
that a non-installed gdb ran from the build dir didn't pick
up the syscall names from the xml file found in its own sources.
I think it should, always, even when at some point distros start
including data in the default system data dir, which is meant for
the system gdb, not for the gdb one is hacking on.

Would anyone object to this?

-- 
Pedro Alves

2009-10-02  Pedro Alves  <pedro@codesourcery.com>

	* gdbinit.in: set data-directory to @srcdir@.

---
 gdb/gdbinit.in |    2 ++
 1 file changed, 2 insertions(+)

Index: src/gdb/gdbinit.in
===================================================================
--- src.orig/gdb/gdbinit.in	2009-10-01 15:15:16.000000000 +0100
+++ src/gdb/gdbinit.in	2009-10-02 20:45:52.000000000 +0100
@@ -16,6 +16,8 @@ dir @srcdir@
 dir .
 set prompt (top-gdb) 
 
+set data-directory @srcdir@
+
 define pdie
   if $argc == 1
     call dump_die ($arg0, 1)

Re: Can we make gdbinit.in set the data-directory to @srcdir@?

[Joel Brobecker]

> 2009-10-02  Pedro Alves  <pedro@codesourcery.com>
> 
> 	* gdbinit.in: set data-directory to @srcdir@.

Indeed, this seems like a good idea.

-- 
Joel

Re: Can we make gdbinit.in set the data-directory to @srcdir@?

[Pedro Alves]

On Friday 02 October 2009 22:05:06, Joel wrote:
> > 2009-10-02  Pedro Alves  <pedro@codesourcery.com>
> > 
> > 	* gdbinit.in: set data-directory to @srcdir@.
> 
> Indeed, this seems like a good idea.

Thanks.  Checked in (with capital S).

-- 
Pedro Alves

Re: Can we make gdbinit.in set the data-directory to @srcdir@?

[Pedro Alves]

On Sunday 04 October 2009 14:53:58, Pedro Alves wrote:
> On Friday 02 October 2009 22:05:06, Joel wrote:
> > > 2009-10-02  Pedro Alves  <pedro@codesourcery.com>
> > > 
> > > 	* gdbinit.in: set data-directory to @srcdir@.
> > 

On second thought, this was a bad idea.  .gdbinit is for the
top (maybe system) gdb, not for the just built, non-installed
gdb.  Sorry for the confusion.  I'll revert.

-- 
Pedro Alves

Re: Can we make gdbinit.in set the data-directory to @srcdir@?

[Sérgio Durigan Júnior]

On Monday 05 October 2009, Pedro Alves wrote:
> On Sunday 04 October 2009 14:53:58, Pedro Alves wrote:
> > On Friday 02 October 2009 22:05:06, Joel wrote:
> > > > 2009-10-02  Pedro Alves  <pedro@codesourcery.com>
> > > >
> > > > 	* gdbinit.in: set data-directory to @srcdir@.
> 
> On second thought, this was a bad idea.  .gdbinit is for the
> top (maybe system) gdb, not for the just built, non-installed
> gdb.  Sorry for the confusion.  I'll revert.


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.  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.

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.

Just my two cents.  Regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

Re: Can we make gdbinit.in set the data-directory to @srcdir@?

[Doug Evans]

2009/10/5 Sérgio Durigan Júnior <sergiodj@linux.vnet.ibm.com>:
> On Monday 05 October 2009, Pedro Alves wrote:
>> On Sunday 04 October 2009 14:53:58, Pedro Alves wrote:
>> > On Friday 02 October 2009 22:05:06, Joel wrote:
>> > > > 2009-10-02  Pedro Alves  <pedro@codesourcery.com>
>> > > >
>> > > >         * gdbinit.in: set data-directory to @srcdir@.
>>
>> On second thought, this was a bad idea.  .gdbinit is for the
>> top (maybe system) gdb, not for the just built, non-installed
>> gdb.  Sorry for the confusion.  I'll revert.
>
>
> 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.  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.
>
> 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.

I think data-dir *is* set on start up, and we want it to.

The testcase should set data-dir to something appropriate instead of
assuming what it is (or isn't).

Maybe the testcase could set data-dir to something that doesn't exist
when testing for non-existent xml files, etc.
Since the syscall files aren't read until the first request, one can
set data-dir to a non-existent directory first, and then do "catch
syscall".

> Just my two cents.  Regards,

Ditto!

Re: Can we make gdbinit.in set the data-directory to @srcdir@?

[Pedro Alves]

On Tuesday 06 October 2009 06:34:39, Doug Evans wrote:

> I think data-dir *is* set on start up, and we want it to.
> 
> The testcase should set data-dir to something appropriate instead of
> assuming what it is (or isn't).

Yes.

> Maybe the testcase could set data-dir to something that doesn't exist
> when testing for non-existent xml files, etc.

Yes.

> Since the syscall files aren't read until the first request, one can
> set data-dir to a non-existent directory first, and then do "catch
> syscall".

FTR, there are a few issues with when is the syscall file read.

First, when the user changes the data-directory, gdb doesn't try
to re-read the syscall file.  This means no ammount of
"set data-directory" to point at the real data directory path
fixes "catch syscall" after gdb having noticed it didn't find
the xml once.

Second, the syscall file and the syscall name mappings aren't
associated with gdbarch, they're global.  This means that e.g., a
gdb configured with native linux debugging support connected to
a !linux remote target of linux remote target !arch than the native
target mistakingly uses the native syscall name mapping.  I'll probably
file PRs for these.

-- 
Pedro Alves

Re: Can we make gdbinit.in set the data-directory to @srcdir@?

[Pedro Alves]

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

Make sure catch-syscall.exp doesn't pick up system/installed syscalls xml.

[Pedro Alves]

On Tuesday 06 October 2009 09:48:04, Pedro Alves wrote:
> 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
> 

I've applied the patch below to fix this.

-- 
Pedro Alves

2009-11-22  Pedro Alves  <pedro@codesourcery.com>

	* gdb.base/catch-syscall.exp (test_catch_syscall_fail_nodatadir)
	(do_syscall_tests_without_xml): Set data-directory to
	/the/path/to/nowhere.

---
 gdb/testsuite/gdb.base/catch-syscall.exp |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: src/gdb/testsuite/gdb.base/catch-syscall.exp
===================================================================
--- src.orig/gdb/testsuite/gdb.base/catch-syscall.exp	2009-11-22 22:23:49.000000000 +0000
+++ src/gdb/testsuite/gdb.base/catch-syscall.exp	2009-11-22 22:54:35.000000000 +0000
@@ -258,6 +258,10 @@ proc test_catch_syscall_fail_nodatadir {
     # Sanitizing.
     delete_breakpoints
 
+    # Make sure GDB doesn't load the syscalls xml from the system data
+    # directory.
+    gdb_test "set data-directory /the/path/to/nowhere" ""
+
     # Testing to see if we receive a warning when calling "catch syscall"
     # without XML support (without datadir).
     set thistest "Catch syscall displays a warning when there is no XML support (no datadir set)"
@@ -382,9 +386,9 @@ proc test_catch_syscall_with_wrong_args_
 proc do_syscall_tests_without_xml {} {
     global gdb_prompt srcdir
 
-    # In this case, we don't need to set GDB's datadir because
-    # we want GDB to display only numbers, not names.  So, let's
-    # begin with the tests.
+    # Make sure GDB doesn't load the syscalls xml from the system data
+    # directory.
+    gdb_test "set data-directory /the/path/to/nowhere" ""
 
     # Let's test if we can catch syscalls without XML support.
     # We should succeed, but GDB is not supposed to print syscall names.