This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Refactor common/target-common into meaningful bits


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]