[RFC/RFA] add struct parse_context to all command functions
Tom Tromey
tromey@redhat.com
Tue Oct 21 19:33:00 GMT 2008
>>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
Ulrich> Great! I was just about to start implementing something along those
Ulrich> lines (to pull current_gdbarch out of the print routines) ... Do you
Ulrich> already have a version of that patch you could share?
I've been meaning to do this for a while, so I went ahead today and
updated my patch to apply to cvs trunk.
I have not written a ChangeLog entry yet, sorry. And, I haven't sent
this through the tester yet either. IOW, this is a raw patch, use at
your own risk, etc.
Basically I moved all print-formatting globals into a structure. To
ensure I didn't miss anything in the value_print/val_print hierarchy,
I actually removed the globals everywhere and replaced remaining
references to them with references to user_print_options (where the
global state now resides).
A couple spots needed to make their own print-options structure; here
I made a couple of convenience functions to copy the global structure
and modify it to suit. I wrote them to initialize an argument to
avoid any possible confusion about ownership (a previous patch had
get_raw_print_options, e.g., return a pointer to a static struct --
but this could be confusing, or even wrong if there is any recursion).
My motivation here is that I wanted to add a new value-printing flag
to control Python-based pretty-printing. I didn't think that adding a
new enum value to val_prettyprint would yield good results; but adding
a new argument to the whole hierarchy looked ugly. On the python
branch, I just used a global -- also ugly, but at least easy to
implement and maintain separately from the trunk.
This patch, I believe, fixes a latent bug. print_command_1 may set
the global inspect_it, but the value is not reset on error. I.e.,
this function is missing a cleanup. I found this by inspection; I
haven't tried testing this theory.
Let me know what you think. I'd like to get something along these
lines into gdb. If this looks reasonable, I'll write a ChangeLog
entry and send it through testing. Or, if you want changes, let me
know that.
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: P
Type: application/octet-stream
Size: 176667 bytes
Desc: the patch
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20081021/efc20044/attachment.obj>
More information about the Gdb-patches
mailing list