This is the mail archive of the
mailing list for the GDB project.
Re: Can we make gdbinit.in set the data-directory to @srcdir@?
2009/10/5 Sérgio Durigan Júnior <firstname.lastname@example.org>:
> 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 ?<email@example.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
> Just my two cents. ?Regards,