This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Refactor common/target-common into meaningful bits
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: lgustavo at codesourcery dot com, "'gdb-patches\ at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Fri, 02 Aug 2013 14:48:44 -0600
- Subject: Re: [PATCH] Refactor common/target-common into meaningful bits
- References: <51FA9649 dot 5060008 at codesourcery dot com> <87vc3pfghs dot fsf at fleche dot redhat dot com> <51FAA061 dot 4050005 at codesourcery dot com> <51FB7BFB dot 90100 at redhat dot com>
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
Pedro> "target" is an overloaded word in GDB-speak. My idea for this new
Pedro> directory, would be for it to hold the native target backend bits.
Pedro> But "target" could also suggest that corelow.c, file.c, remote.c, etc.
Pedro> should be put in this directory, while I don't think they should.
I've been thinking about this a bit since the discussion yesterday.
I think I'm generally in favor of using the names Luis already has.
The basic reason I have is that I think that, by and large, gdb's module
boundaries make sense. I may quibble with some exact lines that have
been drawn (and certainly I dislike the insides of some modules), but by
and large the modules, at least as I understand the breakdown, have
proven resilient.
I agree that "target" is not the best possible name de novo. However,
it is the nature of language to overload words with meanings -- the
norm, not the exception -- and furthermore "target" is the name
historically chosen inside gdb to represent the connection between the
core (+ CLI) and the back end.
You had a few specific issues, which I've quoted & will address below.
Pedro> Sounds like a better name for this native target backend directory
Pedro> should be invented. GDB uses *-nat.c naming for most of
Pedro> these files, while GDBserver uses *-low.c.
I think it's fine to use "nat" in the same way that gdb does now.
Looking at the current patch, though, I don't see anything "nat" in
there. The ptrace options discovery bits could go there, but that
wasn't addressed in this thread IIRC.
Pedro> These new target-resume.h, target-wait.h, target-waitstatus.h,
Pedro> target-waitstatus.c files might be looked at as actually something
Pedro> else. This is code defining the interface between GDB core and
Pedro> target_ops, and as such is used by all sort of targets on the
Pedro> GDB side (remote.c, etc.). I'm not sure they should go in the same
Pedro> directory as the *-nat.c, etc. files.
These seem like classic "target" bits to me.
Pedro> In a world where we fuse gdb's and gdbserver's target backends, it's
Pedro> not clear to me at this point whether we'll end up with only one
Pedro> "struct target_ops"
That's ok though. We can use subclassing. We will need to come up with
new names, but it seems premature to worry about that.
Tom