* target-dependent .gdbinit
@ 2002-12-28 10:59 Felix Lee
2003-01-02 15:08 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Felix Lee @ 2002-12-28 10:59 UTC (permalink / raw)
To: gdb
So I'm thinking I want gdb to read ~/.gdbinit-$target after
~/.gdbinit. Does that seem like a sensible thing to do?
I'm wary of making target a special case. My feeling is I'd
want a single .gdbinit file that has some form of #if for
target or host or gdb version or other conditions. But I'm
not sure that's all that useful. The added complexity
doesn't seem to be worth it.
But target is already a special case sometimes, because
there's .vxgdbinit and such.
Also, behavior like this could be easily synthesized with a
front-end script that ran gdb with the right -x options.
The rationale for putting it into gdb: it's standardization.
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: target-dependent .gdbinit
2002-12-28 10:59 target-dependent .gdbinit Felix Lee
@ 2003-01-02 15:08 ` Andrew Cagney
2003-01-02 18:53 ` Felix Lee
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2003-01-02 15:08 UTC (permalink / raw)
To: Felix Lee; +Cc: gdb
> So I'm thinking I want gdb to read ~/.gdbinit-$target after
> ~/.gdbinit. Does that seem like a sensible thing to do?
>
> I'm wary of making target a special case. My feeling is I'd
> want a single .gdbinit file that has some form of #if for
> target or host or gdb version or other conditions. But I'm
> not sure that's all that useful. The added complexity
> doesn't seem to be worth it.
>
> But target is already a special case sometimes, because
> there's .vxgdbinit and such.
Hmm, something else to delete ....
> Also, behavior like this could be easily synthesized with a
> front-end script that ran gdb with the right -x options.
> The rationale for putting it into gdb: it's standardization.
how about something like:
(gdb) eval source ~/.gdbinit-$target
?
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: target-dependent .gdbinit
2003-01-02 15:08 ` Andrew Cagney
@ 2003-01-02 18:53 ` Felix Lee
2003-01-02 19:13 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Felix Lee @ 2003-01-02 18:53 UTC (permalink / raw)
To: gdb
Andrew Cagney <ac131313@redhat.com>:
> how about something like:
> (gdb) eval source ~/.gdbinit-$target
well, there's still the standardization point. if gdb did
this automatically, then people could rely on that behavior
in arbitrary installations. otherwise, people will
synthesize this behavior themselves in different ways. one
installation might have .gdb.$target, another
.gdbinit.$target, or .vxgdbinit, etc.
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: target-dependent .gdbinit
2003-01-02 18:53 ` Felix Lee
@ 2003-01-02 19:13 ` Andrew Cagney
2003-01-02 20:04 ` Felix Lee
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2003-01-02 19:13 UTC (permalink / raw)
To: Felix Lee; +Cc: gdb
> Andrew Cagney <ac131313@redhat.com>:
>
>> how about something like:
>> (gdb) eval source ~/.gdbinit-$target
>
>
> well, there's still the standardization point. if gdb did
> this automatically, then people could rely on that behavior
> in arbitrary installations. otherwise, people will
> synthesize this behavior themselves in different ways. one
> installation might have .gdb.$target, another
> .gdbinit.$target, or .vxgdbinit, etc.
It should be kept simple. A GDB install should only read `.gdbinit'
(the vx hacks, I think, should just go). A user is then free to
customize their .gdbinit to do things like read .gdbinit-$target, or
even conditionally interpret sections of the init file.
If GDB's scripting language isn't powerful enough to handle this then
the scripting language needs to be fixed.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: target-dependent .gdbinit
2003-01-02 19:13 ` Andrew Cagney
@ 2003-01-02 20:04 ` Felix Lee
2003-01-02 20:17 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Felix Lee @ 2003-01-02 20:04 UTC (permalink / raw)
To: gdb
Andrew Cagney <ac131313@redhat.com>:
> It should be kept simple. A GDB install should only read `.gdbinit'
> (the vx hacks, I think, should just go). A user is then free to
> customize their .gdbinit to do things like read .gdbinit-$target, or
> even conditionally interpret sections of the init file.
yes, but if I'm the gdb maintainer for a site installation,
then sometimes I'll want site-wide gdbinit to handle
pecularities of the site. telling all the users, "put this
in your .gdbinit" is unwieldy, especially if it may change
in the future.
specific instance of target-dependent .gdbinit: I've got a
gdb that will examine core files from a target OS with
shared library support. gdb shouldn't try to map in the
host OS shared libraries. the simple solution is to set
solib-absolute-prefix to a location that has the target OS
shared libs. this is something you'd want to do in a
target-specific .gdbinit. there is not necessarily one
setting that applies to the entire site.
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: target-dependent .gdbinit
2003-01-02 20:04 ` Felix Lee
@ 2003-01-02 20:17 ` Daniel Jacobowitz
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-01-02 20:17 UTC (permalink / raw)
To: Felix Lee; +Cc: gdb
On Thu, Jan 02, 2003 at 12:03:17PM -0800, Felix Lee wrote:
> Andrew Cagney <ac131313@redhat.com>:
> > It should be kept simple. A GDB install should only read `.gdbinit'
> > (the vx hacks, I think, should just go). A user is then free to
> > customize their .gdbinit to do things like read .gdbinit-$target, or
> > even conditionally interpret sections of the init file.
>
> yes, but if I'm the gdb maintainer for a site installation,
> then sometimes I'll want site-wide gdbinit to handle
> pecularities of the site. telling all the users, "put this
> in your .gdbinit" is unwieldy, especially if it may change
> in the future.
>
> specific instance of target-dependent .gdbinit: I've got a
> gdb that will examine core files from a target OS with
> shared library support. gdb shouldn't try to map in the
> host OS shared libraries. the simple solution is to set
> solib-absolute-prefix to a location that has the target OS
> shared libs. this is something you'd want to do in a
> target-specific .gdbinit. there is not necessarily one
> setting that applies to the entire site.
FYI, since it keeps coming up (this applies to Kris's message of a few
minutes ago also :) - I'm going to have a more specific solution for
this one soon. I'm waiting for comments on the binutils sysroot patch
before I post the GDB one; too much going at once.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-01-02 20:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-28 10:59 target-dependent .gdbinit Felix Lee
2003-01-02 15:08 ` Andrew Cagney
2003-01-02 18:53 ` Felix Lee
2003-01-02 19:13 ` Andrew Cagney
2003-01-02 20:04 ` Felix Lee
2003-01-02 20:17 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox