global, target-specific, init files

global, target-specific, init files

[Jerome Guitton]

Hello everyone,

I'd like to have your opinion about the utility of a couple of
features that we are considering to implement in AdaCore. This mostly
has to do with improvement to the init file. Here are the two features
that we are missing:


1) target-specific settings: .gdbinit does not make it easy to have
some settings/commands that should be executed for a particular
system/target.  Let me give an example to clarify this claim: suppose
that, on a linux host, you build and debug both native applications
and cross applications.  Let's say that the cross target is some
real-time flavour of linux. When you run the cross gdb, you would have
to do a couple of "set solib-search-path"/"set solib-absolute-path"
commands after starting the debugger, in order to debug with the
appropriate libc/threads... You would like to have it done
automatically, by .gdbinit; I may be wrong, but I do not know any way
to execute a set of commands only when the cross debugger is
executed. Or maybe there is a way to test the configure target?

2) global, "user-independant", init file: At startup, gdb will load
the user-specific gdbinit (in $HOME) and the local gdbinit (in current
dir); before these two files, it would be useful to load an init file
that is valid for several users. Take the example I gave before, and
suppose now that a sysadmin has to install the cross gdb I was
describing and would like to make sure that the programmers will have
the "set solib" commands executed before they actually use the debugger. He
can of course document the issue, ask these programmers to modify
their own user-specific gdbinit to include these commands... but I am
pretty sure that it would prefer to have it done in some general config
file (say <prefix>/etc/gdbinit).


To deal with these two problems, here is what I would suggest:
1) Have target-specific gdb init files, named after the configure target
name (e.g. .powerpc-elf-gdbinit). .gdbinit would be the target-independant
gdb init file;
2) Have "global" init files located in <prefix>/etc (if the gdb executable
is installed in <prefix>/bin; <prefix> would be re-computed by gdb at run
time, just like gcc does for GCC_PREFIX).

In other words, here is what GDB would do at startup:

   1. Sets up the command interpreter as specified by the command line.

   2. Reads the global target-independant init file (if any) in
   <prefix>/etc (e.g. <prefix>/etc/gdinit) and executes all the
   commands in that file.

   3. Reads the global target-specific init file (if any) in
   <prefix>/etc (e.g. <prefix>/etc/powerpc-elf-gdinit) and executes
   all the commands in that file.

   4. Reads and executes the target-independant and target-specific
   init files (if any) in your home directory.

   3. Processes command line options and operands.

   4. Reads and executes the commands from init files (if any) in the
   current working directory.

   5. Reads command files specified by the `-x' option.

   6. Reads the command history recorded in the history file.

I would take care of proposing a patch if/when we reach an agreement.
Opinions/thoughts?

Thanks,
Jerome

Re: global, target-specific, init files

[Daniel Jacobowitz]

On Sun, Dec 14, 2008 at 01:45:49PM +0100, Jerome Guitton wrote:
> To deal with these two problems, here is what I would suggest:
> 1) Have target-specific gdb init files, named after the configure target
> name (e.g. .powerpc-elf-gdbinit). .gdbinit would be the target-independant
> gdb init file;
> 2) Have "global" init files located in <prefix>/etc (if the gdb executable
> is installed in <prefix>/bin; <prefix> would be re-computed by gdb at run
> time, just like gcc does for GCC_PREFIX).

You should be able to use one solution to solve both of your
problems.  Pass the name of the global initialization file on GDB's
configure line, and put $target in the name of the file.  Have
the target-specific file load any global file.

I can save you some time, if you'd like.  I recently posted a patch
for user-defined subcommands; the other half of the project which
produced that patch was a global gdbinit file, and I can separate out
the rest of that patch for you this week.

-- 
Daniel Jacobowitz
CodeSourcery

Re: global, target-specific, init files

[Jerome Guitton]

Daniel Jacobowitz (drow@false.org):

> On Sun, Dec 14, 2008 at 01:45:49PM +0100, Jerome Guitton wrote:
> > To deal with these two problems, here is what I would suggest:
> > 1) Have target-specific gdb init files, named after the configure target
> > name (e.g. .powerpc-elf-gdbinit). .gdbinit would be the target-independant
> > gdb init file;
> > 2) Have "global" init files located in <prefix>/etc (if the gdb executable
> > is installed in <prefix>/bin; <prefix> would be re-computed by gdb at run
> > time, just like gcc does for GCC_PREFIX).
> 
> You should be able to use one solution to solve both of your
> problems.  Pass the name of the global initialization file on GDB's
> configure line, and put $target in the name of the file.  Have
> the target-specific file load any global file.

Let me make sure that I understand your suggestion. We would have a new
configure option in gdb, let's say --global-init-file=GDBINIT;
GDBINIT would be the name of this global init file; the path to
this init file would be <prefix>/etc/GDBINIT (would it)?

About the target-specific file, I am not sure I understand your
suggestion. I am confused: I was talking about three target-specific
files, actually. Let's say: the global target-specific init, the
user-specific target-specific init (in $HOME), the local
target-specific init (in current dir). Not sure that these three
options are really useful. In the scenario that I gave, only the
global target-specific init is needed. So my question would be: which
target-specific are you actually referring to?


> I can save you some time, if you'd like.  I recently posted a patch
> for user-defined subcommands; the other half of the project which
> produced that patch was a global gdbinit file, and I can separate out
> the rest of that patch for you this week.

That would certainly be very useful, thanks!

Re: global, target-specific, init files

[Daniel Jacobowitz]

On Mon, Dec 15, 2008 at 12:58:30PM +0100, Jerome Guitton wrote:
> Let me make sure that I understand your suggestion. We would have a new
> configure option in gdb, let's say --global-init-file=GDBINIT;
> GDBINIT would be the name of this global init file; the path to
> this init file would be <prefix>/etc/GDBINIT (would it)?

Well, we took a full path.  So you'd give it
$prefix/etc/$target-gdbinit in your case.  The path automatically
relocates along with an installed GDB.  Come to think of it,
I'm not sure entirely how to handle relocation if you want to source
another file in the same directory, but there's probably a logical
extension of the current mechanism for that.

Does that clarify?

Here's the patch.  I've only tested that it applies, but we're using
it against an older GDB internally.

-- 
Daniel Jacobowitz
CodeSourcery

2008-12-15  Daniel Jacobowitz  <dan@codesourcery.com>

	* configure, config.in: Regenerated.
	* configure.ac: Add --with-system-gdbinit.
	* main.c (system_gdbinit): New.
	(captured_main): Relocate system_gdbinit.  Load it before
	$HOME/.gdbinit.

2008-12-15  Daniel Jacobowitz  <dan@codesourcery.com>

	* gdb.texinfo (Startup): Document --with-system-gdbinit.

Index: config.in
===================================================================
RCS file: /cvs/src/src/gdb/config.in,v
retrieving revision 1.103
diff -u -p -r1.103 config.in
--- config.in	6 Aug 2008 19:41:31 -0000	1.103
+++ config.in	15 Dec 2008 15:40:34 -0000
@@ -646,6 +646,13 @@
 /* Define to 1 if you have the ANSI C header files. */
 #undef STDC_HEADERS
 
+/* System-wide gdbinit file. */
+#undef SYSTEM_GDBINIT
+
+/* Define if the system-wide gdbinit file should be relocated when GDB is
+   moved. */
+#undef SYSTEM_GDBINIT_RELOCATABLE
+
 /* Define if <thread_db.h> has the TD_NOTALLOC error code. */
 #undef THREAD_DB_HAS_TD_NOTALLOC
 
Index: configure
===================================================================
RCS file: /cvs/src/src/gdb/configure,v
retrieving revision 1.262
diff -u -p -r1.262 configure
--- configure	21 Nov 2008 22:35:57 -0000	1.262
+++ configure	15 Dec 2008 15:40:36 -0000
@@ -895,6 +895,7 @@ Optional Packages:
                           on systems with version 2 of the GNU C library
                           (use with caution on other system)
   --with-sysroot=DIR Search for usr/lib et al within DIR.
+  --with-system-gdbinit=file       Automatically load a system-wide gdbinit file
   --with-tcl              directory containing tcl configuration (tclConfig.sh)
   --with-tk               directory containing tk configuration (tkConfig.sh)
   --with-x                use the X Window System
@@ -19417,6 +19418,49 @@ fi;
 
 
 
+system_gdbinit=
+
+# Check whether --with-system-gdbinit or --without-system-gdbinit was given.
+if test "${with_system_gdbinit+set}" = set; then
+  withval="$with_system_gdbinit"
+  system_gdbinit=${withval}
+fi;
+
+
+  test "x$prefix" = xNONE && prefix="$ac_default_prefix"
+  test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'
+  ac_define_dir=`eval echo $system_gdbinit`
+  ac_define_dir=`eval echo $ac_define_dir`
+
+cat >>confdefs.h <<_ACEOF
+#define SYSTEM_GDBINIT "$ac_define_dir"
+_ACEOF
+
+
+
+if test "x$prefix" = xNONE; then
+  test_prefix=$ac_default_prefix
+else
+  test_prefix=$prefix
+fi
+if test "x$exec_prefix" = xNONE || test "x$exec_prefix" = 'x${prefix}'; then
+  test_exec_prefix=$test_prefix
+else
+  test_exec_prefix=$exec_prefix
+fi
+case ${system_gdbinit} in
+ "${test_prefix}"|"${test_prefix}/"*|\
+ "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
+ '${prefix}'|'${prefix}/'*|\
+ '${exec_prefix}'|'${exec_prefix}/'*)
+
+cat >>confdefs.h <<\_ACEOF
+#define SYSTEM_GDBINIT_RELOCATABLE 1
+_ACEOF
+
+   ;;
+esac
+
 # Check whether --enable-werror or --disable-werror was given.
 if test "${enable_werror+set}" = set; then
   enableval="$enable_werror"
Index: configure.ac
===================================================================
RCS file: /cvs/src/src/gdb/configure.ac,v
retrieving revision 1.82
diff -u -p -r1.82 configure.ac
--- configure.ac	21 Nov 2008 22:35:58 -0000	1.82
+++ configure.ac	15 Dec 2008 15:40:36 -0000
@@ -1488,6 +1488,34 @@ AC_ARG_WITH(sysroot,
 AC_SUBST(TARGET_SYSTEM_ROOT)
 AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
 
+system_gdbinit=
+AC_ARG_WITH(system-gdbinit,
+[  --with-system-gdbinit=file       Automatically load a system-wide gdbinit file],
+[system_gdbinit=${withval}])
+
+AC_DEFINE_DIR(SYSTEM_GDBINIT, system_gdbinit,
+              [System-wide gdbinit file.])
+
+if test "x$prefix" = xNONE; then
+  test_prefix=$ac_default_prefix
+else
+  test_prefix=$prefix
+fi
+if test "x$exec_prefix" = xNONE || test "x$exec_prefix" = 'x${prefix}'; then
+  test_exec_prefix=$test_prefix
+else
+  test_exec_prefix=$exec_prefix
+fi
+case ${system_gdbinit} in
+ "${test_prefix}"|"${test_prefix}/"*|\
+ "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
+ '${prefix}'|'${prefix}/'*|\
+ '${exec_prefix}'|'${exec_prefix}/'*)
+  AC_DEFINE(SYSTEM_GDBINIT_RELOCATABLE, 1,
+            [Define if the system-wide gdbinit file should be relocated when GDB is moved.])
+   ;;
+esac
+
 AC_ARG_ENABLE(werror,
   [  --enable-werror    treat compile warnings as errors],
   [case "${enableval}" in
Index: main.c
===================================================================
RCS file: /cvs/src/src/gdb/main.c,v
retrieving revision 1.70
diff -u -p -r1.70 main.c
--- main.c	29 Jul 2008 14:16:15 -0000	1.70
+++ main.c	15 Dec 2008 15:40:36 -0000
@@ -83,6 +83,9 @@ int return_child_result_value = -1;
 /* Whether to enable writing into executable and core files */
 extern int write_files;
 
+/* The system-wide gdbinit file.  */
+static char *system_gdbinit = SYSTEM_GDBINIT;
+
 static void print_gdb_help (struct ui_file *);
 
 /* These two are used to set the external editor commands when gdb is farming
@@ -268,6 +271,24 @@ captured_main (void *data)
 	}
     }
 
+#ifdef SYSTEM_GDBINIT_RELOCATABLE
+  system_gdbinit = make_relative_prefix (argv[0], BINDIR, SYSTEM_GDBINIT);
+  if (system_gdbinit)
+    {
+      struct stat s;
+      int res = 0;
+
+      if (stat (system_gdbinit, &s) == 0)
+	res = 1;
+
+      if (res == 0)
+	{
+	  xfree (system_gdbinit);
+	  system_gdbinit = SYSTEM_GDBINIT;
+	}
+    }
+#endif
+
   /* There will always be an interpreter.  Either the one passed into
      this captured main, or one specified by the user at start up, or
      the console.  Initialize the interpreter to the one requested by 
@@ -679,6 +700,13 @@ Excess command line arguments ignored. (
   quit_pre_print = error_pre_print;
   warning_pre_print = _("\nwarning: ");
 
+  /* Read and execute the system-wide gdbinit file, if it exists.
+     This is done *before* all the command line arguments are
+     processed; it sets global parameters, which are independent of
+     what file you are debugging or what directory you are in.  */
+  if (system_gdbinit[0] && !inhibit_gdbinit)
+    catch_command_errors (source_script, system_gdbinit, 0, RETURN_MASK_ALL);
+
   /* Read and execute $HOME/.gdbinit file, if it exists.  This is done
      *before* all the command line arguments are processed; it sets
      global parameters, which are independent of what file you are
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.537
diff -u -p -r1.537 gdb.texinfo
--- doc/gdb.texinfo	27 Nov 2008 09:23:01 -0000	1.537
+++ doc/gdb.texinfo	15 Dec 2008 15:40:42 -0000
@@ -1219,6 +1219,10 @@ Sets up the command interpreter as speci
 
 @item
 @cindex init file
+Reads the system-wide @dfn{init file} (if @option{--with-system-gdbinit} was
+used when building @value{GDBN}) and executes all the commands in that file.
+
+@item
 Reads the @dfn{init file} (if any) in your home directory@footnote{On
 DOS/Windows systems, the home directory is the one pointed to by the
 @code{HOME} environment variable.} and executes all the commands in

Re: global, target-specific, init files

[Jerome Guitton]

Daniel Jacobowitz (drow@false.org):

> Well, we took a full path.  So you'd give it
> $prefix/etc/$target-gdbinit in your case.  The path automatically
> relocates along with an installed GDB.  Come to think of it,
> I'm not sure entirely how to handle relocation if you want to source
> another file in the same directory, but there's probably a logical
> extension of the current mechanism for that.
> 
> Does that clarify?

It does; I understand now. And I like the way you fixed the problem,
much simpler than my proposal. I have tested it and it works like a
charm. Would it make sense to have this merged into the FSF tree?

Re: global, target-specific, init files

[Michael Snyder]

Jerome Guitton wrote:
> Daniel Jacobowitz (drow@false.org):
> 
>> Well, we took a full path.  So you'd give it
>> $prefix/etc/$target-gdbinit in your case.  The path automatically
>> relocates along with an installed GDB.  Come to think of it,
>> I'm not sure entirely how to handle relocation if you want to source
>> another file in the same directory, but there's probably a logical
>> extension of the current mechanism for that.
>>
>> Does that clarify?
> 
> It does; I understand now. And I like the way you fixed the problem,
> much simpler than my proposal. I have tested it and it works like a
> charm. Would it make sense to have this merged into the FSF tree?
> 

FWIW, I think it would make sense...

Re: global, target-specific, init files

[Jerome Guitton]

Michael Snyder (msnyder@vmware.com):

> Jerome Guitton wrote:
>> Daniel Jacobowitz (drow@false.org):
>> 
>>> Well, we took a full path.  So you'd give it
>>> $prefix/etc/$target-gdbinit in your case.  The path automatically
>>> relocates along with an installed GDB.  Come to think of it,
>>> I'm not sure entirely how to handle relocation if you want to source
>>> another file in the same directory, but there's probably a logical
>>> extension of the current mechanism for that.
>>> 
>>> Does that clarify?
>> 
>> It does; I understand now. And I like the way you fixed the problem,
>> much simpler than my proposal. I have tested it and it works like a
>> charm. Would it make sense to have this merged into the FSF tree?
>> 
> 
> FWIW, I think it would make sense...

OK, great. Daniel, if you are OK, I can take care of posting the patch
to gdb-patches and commit it if it is approved.