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