* [RFC] New function find_target_at_stratum() ?
@ 2006-01-12 6:09 Joel Brobecker
2006-01-12 20:48 ` Mark Kettenis
0 siblings, 1 reply; 3+ messages in thread
From: Joel Brobecker @ 2006-01-12 6:09 UTC (permalink / raw)
To: gdb-patches
Hello,
While learning a bit more about the target vector and the target
stack, and how it is used, I noticed that two files, sol-thread.c
and uw-thread.c make an explicit reference to the procfs_ops target
vector.
Looking at the code, the idea is to implement one target method at
the thread level by first using the same method at the process level
and then by performing the necessary operations to handle threads.
For instance:
static void
sol_thread_attach (char *args, int from_tty)
{
procfs_ops.to_attach (args, from_tty);
/* Must get symbols from shared libraries before libthread_db can run! */
solib_add (NULL, from_tty, (struct target_ops *) 0, auto_solib_add);
[...]
}
This is really nit-picking, but I think we can get rid of these explicit
references and then make procfs_ops static. The way to do this would be
to change the reference to procfs_ops by a function that would return
the target vector at the process level. Ie:
find_target_ops_at_stratum (process_stratum).to_attach (args, from_tty);
This means adding a new function in target.h/target.c.
To be complete, I think the current public interface already allows us
to find the target vector at any stratum. Just by using current_target
and find_target_beneath(). I just thought that the new proposed function
might be of general interest?
Thoughts?
--
Joel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] New function find_target_at_stratum() ?
2006-01-12 6:09 [RFC] New function find_target_at_stratum() ? Joel Brobecker
@ 2006-01-12 20:48 ` Mark Kettenis
2006-01-13 4:05 ` Daniel Jacobowitz
0 siblings, 1 reply; 3+ messages in thread
From: Mark Kettenis @ 2006-01-12 20:48 UTC (permalink / raw)
To: brobecker; +Cc: gdb-patches
> Date: Thu, 12 Jan 2006 10:09:39 +0400
> From: Joel Brobecker <brobecker@adacore.com>
>
> Hello,
>
> While learning a bit more about the target vector and the target
> stack, and how it is used, I noticed that two files, sol-thread.c
> and uw-thread.c make an explicit reference to the procfs_ops target
> vector.
>
> Looking at the code, the idea is to implement one target method at
> the thread level by first using the same method at the process level
> and then by performing the necessary operations to handle threads.
>
> [snip]
>
> To be complete, I think the current public interface already allows us
> to find the target vector at any stratum. Just by using current_target
> and find_target_beneath(). I just thought that the new proposed function
> might be of general interest?
>
> Thoughts?
Well, what sol-thread does is really completely bogus. It should
simply be rewritten such that it can sit on top of both the process
and core target and use find_target_beneath().
Mark
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] New function find_target_at_stratum() ?
2006-01-12 20:48 ` Mark Kettenis
@ 2006-01-13 4:05 ` Daniel Jacobowitz
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Jacobowitz @ 2006-01-13 4:05 UTC (permalink / raw)
To: Mark Kettenis; +Cc: brobecker, gdb-patches
On Thu, Jan 12, 2006 at 09:48:00PM +0100, Mark Kettenis wrote:
> Well, what sol-thread does is really completely bogus. It should
> simply be rewritten such that it can sit on top of both the process
> and core target and use find_target_beneath().
I agree - same thing applies to thread-db and the Linux native target.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-01-13 4:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-12 6:09 [RFC] New function find_target_at_stratum() ? Joel Brobecker
2006-01-12 20:48 ` Mark Kettenis
2006-01-13 4:05 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox