From: Andrew Cagney <ac131313@redhat.com>
To: Kris Warkentin <kewarken@qnx.com>,
Elena Zannoni <ezannoni@redhat.com>,
Fernando Nasser <fnasser@redhat.com>
Cc: Felix Lee <felix.1@canids.net>, gdb@sources.redhat.com
Subject: Re: patch to use target specific .gdbinit file
Date: Mon, 13 Jan 2003 18:53:00 -0000 [thread overview]
Message-ID: <3E230B07.8030607@redhat.com> (raw)
In-Reply-To: <0d6601c2bb1e$70a94670$0202040a@catdog>
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
>
>
next prev parent reply other threads:[~2003-01-13 18:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-10 17:11 Kris Warkentin
2003-01-10 22:44 ` Felix Lee
2003-01-13 16:12 ` Kris Warkentin
2003-01-13 18:53 ` Andrew Cagney [this message]
2003-01-13 19:01 ` Kris Warkentin
2003-01-13 19:38 ` Andrew Cagney
2003-01-13 21:07 ` Kris Warkentin
2003-01-13 21:42 ` Andrew Cagney
2003-01-13 22:17 ` Kris Warkentin
2003-01-13 22:30 ` Andrew Cagney
2003-01-14 19:11 ` Kris Warkentin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E230B07.8030607@redhat.com \
--to=ac131313@redhat.com \
--cc=ezannoni@redhat.com \
--cc=felix.1@canids.net \
--cc=fnasser@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=kewarken@qnx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox