* [RFA] Remove unnecessary target defaults.
@ 2008-08-15 12:46 Vladimir Prus
2008-08-15 13:08 ` Pedro Alves
2008-08-16 20:15 ` Daniel Jacobowitz
0 siblings, 2 replies; 9+ messages in thread
From: Vladimir Prus @ 2008-08-15 12:46 UTC (permalink / raw)
To: gdb-patches
In current GDB, at the bottom of the target stack, we always have dummy
target, which defines some target methods, including to_create_inferiour,
and to_attach. Those are implemented by calling find_default_attach
and find_default_create_inferior, which will call 'error' when nothing
is found.
On the other hand, update_current_target tries to set a default value
for those functions -- but because dummy target is always there, such
defaulting is not necessary. This patch removes it. No regressions on x86.
OK?
- Volodya
* target.c (maybe_kill_then_attach)
(maybe_kill_then_create_inferior): Remove.
(update_current_target): Do not default to_attach,
to_create_inferiour, to_is_async_p.
---
gdb/target.c | 27 ---------------------------
1 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/gdb/target.c b/gdb/target.c
index 0dbe49b..050f71b 100644
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -44,8 +44,6 @@
static void target_info (char *, int);
-static void maybe_kill_then_attach (char *, int);
-
static void kill_or_be_killed (int);
static void default_terminal_info (char *, int);
@@ -358,21 +356,6 @@ kill_or_be_killed (int from_tty)
tcomplain ();
}
-static void
-maybe_kill_then_attach (char *args, int from_tty)
-{
- kill_or_be_killed (from_tty);
- target_attach (args, from_tty);
-}
-
-static void
-maybe_kill_then_create_inferior (char *exec, char *args, char **env,
- int from_tty)
-{
- kill_or_be_killed (0);
- target_create_inferior (exec, args, env, from_tty);
-}
-
/* Go through the target stack from top to bottom, copying over zero
entries in current_target, then filling in still empty entries. In
effect, we are doing class inheritance through the pushed target
@@ -500,8 +483,6 @@ update_current_target (void)
de_fault (to_close,
(void (*) (int))
target_ignore);
- de_fault (to_attach,
- maybe_kill_then_attach);
de_fault (to_post_attach,
(void (*) (int))
target_ignore);
@@ -584,8 +565,6 @@ update_current_target (void)
de_fault (to_lookup_symbol,
(int (*) (char *, CORE_ADDR *))
nosymbol);
- de_fault (to_create_inferior,
- maybe_kill_then_create_inferior);
de_fault (to_post_startup_inferior,
(void (*) (ptid_t))
target_ignore);
@@ -640,12 +619,6 @@ update_current_target (void)
de_fault (to_pid_to_exec_file,
(char *(*) (int))
return_zero);
- de_fault (to_can_async_p,
- (int (*) (void))
- return_zero);
- de_fault (to_is_async_p,
- (int (*) (void))
- return_zero);
de_fault (to_async,
(void (*) (void (*) (enum inferior_event_type, void*), void*))
tcomplain);
--
1.5.3.5
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Remove unnecessary target defaults.
2008-08-15 12:46 [RFA] Remove unnecessary target defaults Vladimir Prus
@ 2008-08-15 13:08 ` Pedro Alves
2008-08-15 14:16 ` Vladimir Prus
2008-08-16 20:15 ` Daniel Jacobowitz
1 sibling, 1 reply; 9+ messages in thread
From: Pedro Alves @ 2008-08-15 13:08 UTC (permalink / raw)
To: gdb-patches; +Cc: Vladimir Prus
On Friday 15 August 2008 13:45:30, Vladimir Prus wrote:
> - de_fault (to_can_async_p,
> - (int (*) (void))
> - return_zero);
> - de_fault (to_is_async_p,
> - (int (*) (void))
> - return_zero);
I believe this is incorrect. You don't notice it when connected
to remote, because those methods are implemented in remote_ops. But,
when connected to e.g., remote-sim.c, and because gdbsim_ops doesn't define
those, you'll inherit the dummy target's implementation, which looks
for asyncness in the default run target instead --- while you should be
looking for asyncness in the remote-sim target.
--
Pedro Alves
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Remove unnecessary target defaults.
2008-08-15 13:08 ` Pedro Alves
@ 2008-08-15 14:16 ` Vladimir Prus
2008-08-15 14:31 ` Pedro Alves
0 siblings, 1 reply; 9+ messages in thread
From: Vladimir Prus @ 2008-08-15 14:16 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
On Friday 15 August 2008 17:08:42 Pedro Alves wrote:
> On Friday 15 August 2008 13:45:30, Vladimir Prus wrote:
>
> > - de_fault (to_can_async_p,
> > - (int (*) (void))
> > - return_zero);
> > - de_fault (to_is_async_p,
> > - (int (*) (void))
> > - return_zero);
>
> I believe this is incorrect. You don't notice it when connected
> to remote, because those methods are implemented in remote_ops. But,
> when connected to e.g., remote-sim.c, and because gdbsim_ops doesn't define
> those, you'll inherit the dummy target's implementation, which looks
> for asyncness in the default run target instead --- while you should be
> looking for asyncness in the remote-sim target.
As we seem to have agreed on IRC, this is pre-existing problem. We inherit
a method before applying defaults, so we'll always inherit dummy's version
of to_is_async_p, and the code I remove above will never manage to change
method to return_zero.
The problem you raise is real, however. I think one approach to solve it
is to just make remote-sim define to_can_async_p. More generic solution
would be to arrange so that if we have a target on process stratum, it
never goes to targets below for to_can_async_p. For example, if we have
- exec
- dummy
and you do run, then target_can_async_p will look at exec, then at dummy,
then find_default_can_async_p will return some results. But if we have
- remote-sim
- exec
- dummy
then target_can_async_p will either invoke a method in remote-sim (if present),
or return 0.
How does this sound?
- Volodya
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Remove unnecessary target defaults.
2008-08-15 14:16 ` Vladimir Prus
@ 2008-08-15 14:31 ` Pedro Alves
2008-08-15 14:41 ` Vladimir Prus
0 siblings, 1 reply; 9+ messages in thread
From: Pedro Alves @ 2008-08-15 14:31 UTC (permalink / raw)
To: Vladimir Prus; +Cc: gdb-patches
On Friday 15 August 2008 15:15:59, Vladimir Prus wrote:
> The problem you raise is real, however. I think one approach to solve it
> is to just make remote-sim define to_can_async_p. More generic solution
> would be to arrange so that if we have a target on process stratum, it
> never goes to targets below for to_can_async_p. For example, if we have
>
> - exec
> - dummy
>
> and you do run, then target_can_async_p will look at exec, then at dummy,
> then find_default_can_async_p will return some results. But if we have
>
>
> - remote-sim
> - exec
> - dummy
>
> then target_can_async_p will either invoke a method in remote-sim (if
> present), or return 0.
>
> How does this sound?
It sounds sound to me. This would be like a generalised version of
inf-child.c, from which all targets that can have execution
inherit.
--
Pedro Alves
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Remove unnecessary target defaults.
2008-08-15 14:31 ` Pedro Alves
@ 2008-08-15 14:41 ` Vladimir Prus
2008-08-15 14:52 ` Pedro Alves
0 siblings, 1 reply; 9+ messages in thread
From: Vladimir Prus @ 2008-08-15 14:41 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
On Friday 15 August 2008 18:30:59 Pedro Alves wrote:
> On Friday 15 August 2008 15:15:59, Vladimir Prus wrote:
>
> > The problem you raise is real, however. I think one approach to solve it
> > is to just make remote-sim define to_can_async_p. More generic solution
> > would be to arrange so that if we have a target on process stratum, it
> > never goes to targets below for to_can_async_p. For example, if we have
> >
> > - exec
> > - dummy
> >
> > and you do run, then target_can_async_p will look at exec, then at dummy,
> > then find_default_can_async_p will return some results. But if we have
> >
> >
> > - remote-sim
> > - exec
> > - dummy
> >
> > then target_can_async_p will either invoke a method in remote-sim (if
> > present), or return 0.
> >
> > How does this sound?
>
> It sounds sound to me. This would be like a generalised version of
> inf-child.c, from which all targets that can have execution
> inherit.
Well, actually, I meant implementing target_can_async_p in such a way that it:
- iterates over all targets
- breaks after it examines a target at process stratum
Of course, we can also have a common target, but it would require manually adjusting
all target on process stratum.
- Volodya
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Remove unnecessary target defaults.
2008-08-15 14:41 ` Vladimir Prus
@ 2008-08-15 14:52 ` Pedro Alves
2008-08-15 15:02 ` Vladimir Prus
0 siblings, 1 reply; 9+ messages in thread
From: Pedro Alves @ 2008-08-15 14:52 UTC (permalink / raw)
To: Vladimir Prus; +Cc: gdb-patches
On Friday 15 August 2008 15:40:53, Vladimir Prus wrote:
> > It sounds sound to me. This would be like a generalised version of
> > inf-child.c, from which all targets that can have execution
> > inherit.
>
> Well, actually, I meant implementing target_can_async_p in such a way that
> it:
>
> - iterates over all targets
> - breaks after it examines a target at process stratum
>
Should work too...
> Of course, we can also have a common target, but it would require manually
> adjusting all target on process stratum.
... yeah. I keep meaning to try adding a base target from which all
targets inherit, so we could perhaps get rid of this INHERIT +
de_fault business, and I somehow thought you could read minds. Well,
you do, but you set it to block dumb ideas. :-)
--
Pedro Alves
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Remove unnecessary target defaults.
2008-08-15 14:52 ` Pedro Alves
@ 2008-08-15 15:02 ` Vladimir Prus
2008-08-15 15:11 ` Pedro Alves
0 siblings, 1 reply; 9+ messages in thread
From: Vladimir Prus @ 2008-08-15 15:02 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
On Friday 15 August 2008 18:52:19 Pedro Alves wrote:
> On Friday 15 August 2008 15:40:53, Vladimir Prus wrote:
>
> > > It sounds sound to me. This would be like a generalised version of
> > > inf-child.c, from which all targets that can have execution
> > > inherit.
> >
> > Well, actually, I meant implementing target_can_async_p in such a way that
> > it:
> >
> > - iterates over all targets
> > - breaks after it examines a target at process stratum
> >
>
> Should work too...
>
> > Of course, we can also have a common target, but it would require manually
> > adjusting all target on process stratum.
>
> ... yeah. I keep meaning to try adding a base target from which all
> targets inherit, so we could perhaps get rid of this INHERIT +
> de_fault business, and I somehow thought you could read minds. Well,
> you do, but you set it to block dumb ideas. :-)
In fact, I cannot shake the feeling that current target stack is several
designs lumped together, and it would be beneficial to switch to a more coherent
design, where, in particular:
- there's base target every other target derives from and most methods of the base
target forward to the target beneath
- dummy target catches all methods
- all INHERIT and de_fault code is removed
- all target_xxx methods (iterating over target stack) are removed, or make just call
current_target->xxx
But this is fairly large thing to do.
- Volodya
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Remove unnecessary target defaults.
2008-08-15 15:02 ` Vladimir Prus
@ 2008-08-15 15:11 ` Pedro Alves
0 siblings, 0 replies; 9+ messages in thread
From: Pedro Alves @ 2008-08-15 15:11 UTC (permalink / raw)
To: Vladimir Prus; +Cc: gdb-patches
On Friday 15 August 2008 16:02:07, Vladimir Prus wrote:
> > ... yeah. I keep meaning to try adding a base target from which all
> > targets inherit, so we could perhaps get rid of this INHERIT +
> > de_fault business, and I somehow thought you could read minds. Well,
> > you do, but you set it to block dumb ideas. :-)
>
> In fact, I cannot shake the feeling that current target stack is several
> designs lumped together, and it would be beneficial to switch to a more
> coherent design, where, in particular:
>
> - there's base target every other target derives from and most methods of
> the base target forward to the target beneath
> - dummy target catches all methods
> - all INHERIT and de_fault code is removed
> - all target_xxx methods (iterating over target stack) are removed, or make
> just call current_target->xxx
>
> But this is fairly large thing to do.
>
Eh, you *do* read minds!
--
Pedro Alves
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Remove unnecessary target defaults.
2008-08-15 12:46 [RFA] Remove unnecessary target defaults Vladimir Prus
2008-08-15 13:08 ` Pedro Alves
@ 2008-08-16 20:15 ` Daniel Jacobowitz
1 sibling, 0 replies; 9+ messages in thread
From: Daniel Jacobowitz @ 2008-08-16 20:15 UTC (permalink / raw)
To: Vladimir Prus; +Cc: gdb-patches
On Fri, Aug 15, 2008 at 04:45:30PM +0400, Vladimir Prus wrote:
>
> In current GDB, at the bottom of the target stack, we always have dummy
> target, which defines some target methods, including to_create_inferiour,
> and to_attach. Those are implemented by calling find_default_attach
> and find_default_create_inferior, which will call 'error' when nothing
> is found.
>
> On the other hand, update_current_target tries to set a default value
> for those functions -- but because dummy target is always there, such
> defaulting is not necessary. This patch removes it. No regressions on x86.
>
> OK?
>
> - Volodya
>
> * target.c (maybe_kill_then_attach)
> (maybe_kill_then_create_inferior): Remove.
> (update_current_target): Do not default to_attach,
> to_create_inferiour, to_is_async_p.
Based on the discussion, this is OK.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-08-16 20:15 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-15 12:46 [RFA] Remove unnecessary target defaults Vladimir Prus
2008-08-15 13:08 ` Pedro Alves
2008-08-15 14:16 ` Vladimir Prus
2008-08-15 14:31 ` Pedro Alves
2008-08-15 14:41 ` Vladimir Prus
2008-08-15 14:52 ` Pedro Alves
2008-08-15 15:02 ` Vladimir Prus
2008-08-15 15:11 ` Pedro Alves
2008-08-16 20:15 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox