patch to use target specific .gdbinit file

patch to use target specific .gdbinit file

[Kris Warkentin]

The following code will allow backend writers to define
EXTRA_GDBINIT_FILENAME to be an alternate filename for sourcing on startup.
For example, since we have gdb versions for 5 different CPU targets, we
allow users to create a $HOME/.ntoCPU-gdbinit.  This is especially handy if
you're dealing with several remote targets that you want to be connected to
every time.  A simple "source .gdbinit" at the end of .ntoCPU-gdbinit gives
a very nice way to have specific initializations followed by generic ones.

cheers,

Kris

Index: top.h
===================================================================
RCS file: /cvs/src/src/gdb/top.h,v
retrieving revision 1.7
diff -u -r1.7 top.h
--- top.h 19 Mar 2002 19:00:04 -0000 1.7
+++ top.h 10 Jan 2003 17:06:43 -0000
@@ -30,6 +30,7 @@
 extern int inhibit_gdbinit;
 extern int epoch_interface;
 extern char gdbinit[];
+extern char *extragdbinit;

 extern void print_gdb_version (struct ui_file *);

Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.69
diff -u -r1.69 top.c
--- top.c 9 Dec 2002 00:59:26 -0000 1.69
+++ top.c 10 Jan 2003 17:06:43 -0000
@@ -77,6 +77,12 @@
 #endif
 char gdbinit[] = GDBINIT_FILENAME;

+#ifndef EXTRA_GDBINIT_FILENAME
+#define EXTRA_GDBINIT_FILENAME 0
+#endif
+
+char *extragdbinit = EXTRA_GDBINIT_FILENAME;
+
 int inhibit_gdbinit = 0;

 /* If nonzero, and GDB has been configured to be able to use windows,
Index: main.c
===================================================================
RCS file: /cvs/src/src/gdb/main.c,v
retrieving revision 1.20
diff -u -r1.20 main.c
--- main.c 26 Sep 2002 17:46:04 -0000 1.20
+++ main.c 10 Jan 2003 17:06:44 -0000
@@ -530,11 +530,30 @@
   homedir = getenv ("HOME");
   if (homedir)
     {
-      homeinit = (char *) alloca (strlen (homedir) +
-      strlen (gdbinit) + 10);
-      strcpy (homeinit, homedir);
-      strcat (homeinit, "/");
-      strcat (homeinit, gdbinit);
+      /* Allow for a target specific gdbinit that will only override
+      the default gdbinit if it exists.  GP QNX Sep 6 2002 */
+      homeinit = 0;
+      if (extragdbinit)
+        {
+          homeinit = (char *) alloca (strlen (homedir) +
+                                      strlen (extragdbinit) + 10);
+
+          strcpy (homeinit, homedir);
+          strcat (homeinit, "/");
+          strcat (homeinit, extragdbinit);
+
+          if (stat (homeinit, &homebuf) < 0)
+              homeinit = 0;
+        }
+
+      if (!homeinit)
+        {
+          homeinit = (char *) alloca (strlen (homedir) +
+        strlen (gdbinit) + 10);
+          strcpy (homeinit, homedir);
+          strcat (homeinit, "/");
+          strcat (homeinit, gdbinit);
+        }

       if (!inhibit_gdbinit)
  {

Re: patch to use target specific .gdbinit file

[Felix Lee]

"Kris Warkentin" <kewarken@qnx.com>:
> The following code will allow backend writers to define
> EXTRA_GDBINIT_FILENAME to be an alternate filename for sourcing on startup.
> For example, since we have gdb versions for 5 different CPU targets, we
> allow users to create a $HOME/.ntoCPU-gdbinit.

1, I'd rather it be a generalized name, like maybe
.gdbinit-$TARGET.  making the name something chosen by the
backend writer feels like it adds unnecessary irregularity.

2, this is going to make it more awkward to create a single
gdb that will debug multiple targets.
--

Re: patch to use target specific .gdbinit file

[Kris Warkentin]

----- Original Message -----
From: "Felix Lee" <felix.1@canids.net>
To: <gdb@sources.redhat.com>
Sent: Friday, January 10, 2003 5:42 PM
Subject: Re: patch to use target specific .gdbinit file


> "Kris Warkentin" <kewarken@qnx.com>:
> > The following code will allow backend writers to define
> > EXTRA_GDBINIT_FILENAME to be an alternate filename for sourcing on
startup.
> > For example, since we have gdb versions for 5 different CPU targets, we
> > allow users to create a $HOME/.ntoCPU-gdbinit.
>
> 1, I'd rather it be a generalized name, like maybe
> .gdbinit-$TARGET.  making the name something chosen by the
> backend writer feels like it adds unnecessary irregularity.

I don't care about the name that much - the reason we did this was to give
the option to backend writers as to whether they wanted it or not.  We could
do something like define GDBINIT_TARGET_SUFFIX which would just create
.gdbinit-GDBINIT_TARGET_SUFFIX if that's better.

> 2, this is going to make it more awkward to create a single
> gdb that will debug multiple targets.

Is there any sort of TARGET variable that is set at runtime that I could
use?  Then we could just do something like #ifdef ENABLE_EXTRA_GDBINIT and
then it would just construct .gdbinit-$TARGET like you suggested.

I like your suggestion better, the only problem being how we generalize the
filename in a consistent and simple way.  It would suck if you wound up with
.gdbinit-nto-i386-some-stupid-target-stuff as your filename. ;-)  Can you
offer any suggestions?

cheers,

Kris

Re: patch to use target specific .gdbinit file

[Andrew Cagney]

Kris,

In the past there was a proposal (patch?) to add a configuration time 
option that would specify a system init file.  There was a patch.  I 
believe that the actual idea was accepted as sound but the patch was 
lost in the paper trail :-(  Can I suggest extending your patch so that 
the mechanism and file are specified at configure time (please don't ask 
me which of --with or --use or --... is the correct option :-).

Some things to think about:
- a command to display the .gdbinit load order (with doco).  If people 
get wierd behavour, being able to dsiplay this will be useful.
- doco (hmm, is there any config doco?) on the config option

Per earlier e-mail, I don't personally thing that .gdbinit-$TARGET is a 
good idea.

You'll want to double check this with both Fernando (CLI) and Elena (top.c).

Andrew

> ----- Original Message -----
> From: "Felix Lee" <felix.1@canids.net>
> To: <gdb@sources.redhat.com>
> Sent: Friday, January 10, 2003 5:42 PM
> Subject: Re: patch to use target specific .gdbinit file
> 
> 
> 
>> "Kris Warkentin" <kewarken@qnx.com>:
> 
>> > The following code will allow backend writers to define
>> > EXTRA_GDBINIT_FILENAME to be an alternate filename for sourcing on
> 
> startup.
> 
>> > For example, since we have gdb versions for 5 different CPU targets, we
>> > allow users to create a $HOME/.ntoCPU-gdbinit.
> 
>>
>> 1, I'd rather it be a generalized name, like maybe
>> .gdbinit-$TARGET.  making the name something chosen by the
>> backend writer feels like it adds unnecessary irregularity.
> 
> 
> I don't care about the name that much - the reason we did this was to give
> the option to backend writers as to whether they wanted it or not.  We could
> do something like define GDBINIT_TARGET_SUFFIX which would just create
> .gdbinit-GDBINIT_TARGET_SUFFIX if that's better.
> 
> 
>> 2, this is going to make it more awkward to create a single
>> gdb that will debug multiple targets.
> 
> 
> Is there any sort of TARGET variable that is set at runtime that I could
> use?  Then we could just do something like #ifdef ENABLE_EXTRA_GDBINIT and
> then it would just construct .gdbinit-$TARGET like you suggested.
> 
> I like your suggestion better, the only problem being how we generalize the
> filename in a consistent and simple way.  It would suck if you wound up with
> .gdbinit-nto-i386-some-stupid-target-stuff as your filename. ;-)  Can you
> offer any suggestions?
> 
> cheers,
> 
> Kris
> 
> 

Re: patch to use target specific .gdbinit file

[Kris Warkentin]

> Kris,
>
> In the past there was a proposal (patch?) to add a configuration time
> option that would specify a system init file.  There was a patch.  I
> believe that the actual idea was accepted as sound but the patch was
> lost in the paper trail :-(  Can I suggest extending your patch so that
> the mechanism and file are specified at configure time (please don't ask
> me which of --with or --use or --... is the correct option :-).

One problem with this (as Felix suggested earlier) is dealing with a gdb
which supports multiple targets.  The whole point is to be able to have
per-target init files and hard wiring it in loses that.  Specifying at
config time would be okay for enable/disable but I think it would be better
to have some sort of system of nomenclature for extra init files.

Here's a question: does a multi-targetted gdb know what it's targetting at
the point of reading the .gdbinit or is this determined later?  Is it
switchable per session?  I'm thinking that another possibility is to have it
check for .gdbinit-$TARGET at the time that the target is determined.

cheers,

Kris

> Some things to think about:
> - a command to display the .gdbinit load order (with doco).  If people
> get wierd behavour, being able to dsiplay this will be useful.
> - doco (hmm, is there any config doco?) on the config option
>
> Per earlier e-mail, I don't personally thing that .gdbinit-$TARGET is a
> good idea.
>
> You'll want to double check this with both Fernando (CLI) and Elena
(top.c).
>
> Andrew

Re: patch to use target specific .gdbinit file

[Andrew Cagney]

> Kris,
>>
>> In the past there was a proposal (patch?) to add a configuration time
>> option that would specify a system init file.  There was a patch.  I
>> believe that the actual idea was accepted as sound but the patch was
>> lost in the paper trail :-(  Can I suggest extending your patch so that
>> the mechanism and file are specified at configure time (please don't ask
>> me which of --with or --use or --... is the correct option :-).
> 
> 
> One problem with this (as Felix suggested earlier) is dealing with a gdb
> which supports multiple targets.  The whole point is to be able to have
> per-target init files and hard wiring it in loses that.  Specifying at
> config time would be okay for enable/disable but I think it would be better
> to have some sort of system of nomenclature for extra init files.

In this thread?
http://sources.redhat.com/ml/gdb/2002-12/msg00328.html

The proposal I'm refering to goes way back.  It was something like:

	--enable-system-gdbinit[=$DATAPREFIX/gdbinit]

That would make it possible to, for instance, to do things like load in 
standard shared library paths.  If a site really wants to add a site 
specific configuration specific gdbinit file they can do that as well vis:

	--enable-system-gdbinit=~/.gdbinit-TARGET --target=TARGET

> Here's a question: does a multi-targetted gdb know what it's targetting at
> the point of reading the .gdbinit or is this determined later?  Is it
> switchable per session?  I'm thinking that another possibility is to have it
> check for .gdbinit-$TARGET at the time that the target is determined.

To clarify something here, target and architecture are separate but very 
related.  GDB configured for a certain TARGET, will support one or more 
architectures.  The x86-64, for instance, also supports i386.

For a normal GDB session, an architecture will be selected twice.  Once 
for the default, and once based on the file that is loaded.  The second 
selection may occure before, during or after, .gdbinit parsing.  The 
`target' however, won't change.

Andrew

Re: patch to use target specific .gdbinit file

[Kris Warkentin]

> > Here's a question: does a multi-targetted gdb know what it's targetting
at
> > the point of reading the .gdbinit or is this determined later?  Is it
> > switchable per session?  I'm thinking that another possibility is to
have it
> > check for .gdbinit-$TARGET at the time that the target is determined.
>
> To clarify something here, target and architecture are separate but very
> related.  GDB configured for a certain TARGET, will support one or more
> architectures.  The x86-64, for instance, also supports i386.
>
> For a normal GDB session, an architecture will be selected twice.  Once
> for the default, and once based on the file that is loaded.  The second
> selection may occure before, during or after, .gdbinit parsing.  The
> `target' however, won't change.

So, to clarify further, a single gdb binary can only support a single target
but multiple architectures?  If this is the case then your method of
enabling this at config time would be just fine.  I was thinking of a (for
instance) ppc/x86 gdb but I didn't think that was possible which was what I
wanted to ask.

cheers,

Kris

Re: patch to use target specific .gdbinit file

[Andrew Cagney]

>> > Here's a question: does a multi-targetted gdb know what it's targetting
> 
> at
> 
>> > the point of reading the .gdbinit or is this determined later?  Is it
>> > switchable per session?  I'm thinking that another possibility is to
> 
> have it
> 
>> > check for .gdbinit-$TARGET at the time that the target is determined.
> 
>>
>> To clarify something here, target and architecture are separate but very
>> related.  GDB configured for a certain TARGET, will support one or more
>> architectures.  The x86-64, for instance, also supports i386.
>>
>> For a normal GDB session, an architecture will be selected twice.  Once
>> for the default, and once based on the file that is loaded.  The second
>> selection may occure before, during or after, .gdbinit parsing.  The
>> `target' however, won't change.
> 
> 
> So, to clarify further, a single gdb binary can only support a single target
> but multiple architectures?

A single gdb executable can support multiple `target architectures'. 
Those architectures, as with i386 / x86-64 are not necessarily of the 
same family.

A single gdb executable can support multiple `target interfaces'.  For 
instance, remote, pmon, and ptrace.

A single gdb executable's configuration options (target interfaces, 
target architectures, initial architecture, ....) are selected by the 
--target=TARGET option (and in the future --enable-targets=...).

>  If this is the case then your method of
> enabling this at config time would be just fine.  I was thinking of a (for
> instance) ppc/x86 gdb but I didn't think that was possible which was what I
> wanted to ask.

Er, that is a single gdb executable supporting ``multiple architectures''.

Andrew

Re: patch to use target specific .gdbinit file

[Kris Warkentin]

>
> Er, that is a single gdb executable supporting ``multiple architectures''.
>

Well then a configure option isn't the answer.  We build GDBs targetting 5
different CPUs.  At the moment, these are separate binaries so it's an easy
matter to have each binary look for a hard-wired $HOME/.gdbinit-nto<CPU>.
Someday, however, we want to multi-arch gdb (as we already have with
binutils) so that we can ship one gdb binary.  That is where the
configure/compile time setting of the extra gdbinit file falls apart.  What
I was asking about earlier was a runtime method of determining the file to
source so that if I use the same binary for multiple targets, I can source a
different file for each one.

I was thinking that we should put a hook in the code that is run when
switching targets to source a target file based on what gdb thinks its
target is at the time.

cheers,

Kris

Re: patch to use target specific .gdbinit file

[Andrew Cagney]

>>
>> Er, that is a single gdb executable supporting ``multiple architectures''.
>>
> 
> 
> Well then a configure option isn't the answer.

A configuration time option answers a problem.  Perhaps not your problem.

>We build GDBs targetting 5
> different CPUs.  At the moment, these are separate binaries so it's an easy
> matter to have each binary look for a hard-wired $HOME/.gdbinit-nto<CPU>.
> Someday, however, we want to multi-arch gdb (as we already have with
> binutils) so that we can ship one gdb binary.  That is where the
> configure/compile time setting of the extra gdbinit file falls apart.  What
> I was asking about earlier was a runtime method of determining the file to
> source so that if I use the same binary for multiple targets, I can source a
> different file for each one.
> 
> I was thinking that we should put a hook in the code that is run when
> switching targets to source a target file based on what gdb thinks its
> target is at the time.

Loading a file, I think, would be a hack, and a pretty nasty one at 
that.  Several suggstions I think of:

- being able to test the architecture from with in a script

- being able to attach commands (hooks in gdb parlance) to things like 
loading a file or adding a new architecture.

Andrew

Re: patch to use target specific .gdbinit file

[Kris Warkentin]

> > Well then a configure option isn't the answer.
>
> A configuration time option answers a problem.  Perhaps not your problem.
>

Well, it answers our problem but isn't extensible to a multi-arch situation.
It sounds like almost everyone agrees that some form of a target specific
extension to the .gdbinit mechanism would be useful but a decision about how
best to implement it hasn't been made.  What I'm going to do for now is
implement it in our port only.  We ship separate gdb binaries and are not
planning on multi-arching soon so our _initialize_nto() function is a
perfect place to put it.  Our documentation states that if
$HOME/.gdbinit-<cpu> exists, it is read instead of $HOME/.gdbinit so I'll
just check for the file, source it and set inhibit_gdbinit if it's found.

Thanks for all the help.  It's interesting to hear from others about the
possible ramifications and alternate solutions to problems.

cheers,

Kris