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

[Doug Evans <dje@google.com>]

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!