[PATCH v4 3/9] add target method delegation

Tom Tromey tromey@redhat.com
Fri Dec 13 22:07:00 GMT 2013


>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> Since this is very repetitive I would consider doing it via a ".defs"
Tom> file and then some macrology to reduce the amount of boilerplate.

I tried this a bit and the result was pretty ugly.

Instead I wrote a little script that can parse just enough of "struct
target_ops" to auto-generate delegation methods when appropriate.

See patch #1 attached below.  This patch just converts the methods used
by the record targets -- that is, it's just a replacement for patch #3
in this series.

Note that the patch isn't ready as-is.  The log entry is wrong and it
does the wrong thing for a couple of the target methods.  I'm curious to
know what you think about the overall shape of it.


As an example of the benefit of this approach, patch #2 converts
to_detach to the new style.  When examining this patch recall that
target-delegates.c is auto-generated.  You can see from this that the
result is less code to maintain.


I then went a little further.  It seems to me that we also need a lot of
boilerplate (not to mention the questionable casts there right now) to
handle the dummy target methods.  Patch #3 makes these into simple
annotations in the target.h file, getting rid of the list of handled
methods from make-target-delegates as well.


Before reaching judgment on patch #3, see patch #4, which converts
to_attach.  I've written a few more like it.


The long-term vision for this approach is to regularize all target
methods according to these rules:

1. Each method will take a "struct target_ops *" as its first argument.

2. Nearly every method will be defaulted to the appropriate delegate_
   method.  There may be exceptions, coded into
   complete_target_initialization.

3. de_fault will be completely eliminated.  INHERIT will be limited to
   the smallest possible list of fields, like to_shortname.  Nearly
   every current_target method will simply delegate.

4. Target API users will call top-level target_* functions that will in
   most cases just call into current_target.

5. Any given to_* method implementation will be guaranteed to be called
   with the target_ops with which it was registered.  (This rule is
   handy on multi-target, where I split out the target_ops vtable from
   the object itself.)


Since I'm on a cleanup kick at the moment, and since a good amount of
this is relevant to the multi-target work, I think it would be good to
start the conversion shortly after 7.7 is branched.

This is a bit difficult since I don't have access to many targets.  I'm
not sure what to do about this aspect.

Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-add-target-method-delegation.patch
Type: text/x-patch
Size: 41184 bytes
Desc: patch #1
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20131213/4fab367c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-convert-to_detach.patch
Type: text/x-patch
Size: 2431 bytes
Desc: patch #2
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20131213/4fab367c/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-add-default-implementation-code.patch
Type: text/x-patch
Size: 18688 bytes
Desc: patch #3
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20131213/4fab367c/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0009-update-to_attach.patch
Type: text/x-patch
Size: 3281 bytes
Desc: patch #4
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20131213/4fab367c/attachment-0003.bin>


More information about the Gdb-patches mailing list