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: pr 11067 patch


On 02/19/10 13:50, Jan Kratochvil wrote:
On Fri, 19 Feb 2010 15:53:45 +0100, Chris Moller wrote:
The problem is that I don't know any way to change the enum
formatting for CLI but leave it alone for MI-.
...
some way to distinguish between running under CLI vs. MI if that's the right
thing to do.

After I wrote the patch below according to Tom Tromey the Python pretty printing applies even to the MI protocol values, therefore IMO it should also apply to this new enum printing which is also some form of pretty printing.

Therefore my MI / CLI suggestion has been already rejected by the Python
pretty printing precedence and the patch below should be dropped.

How about this: The existing patch contains a test


     if (options->summary || recurse != 0)
         fputs_filtered (TYPE_FIELD_NAME (type, i), stream);
   else {
      /* new formatting stuff */
   }

That limited the format change to unsummarised top-level "p <enum thingy>" circumstances. If I make that test

     if (options->summary || recurse != 0 ||
                ui_out_is_mi_like_p (interp_ui_out
   (top_level_interpreter ())))

i.e., checking if the print is to an MI whatever-it-is, the MI tests that failed under the original patch (mi-var-display and mi2-var-display) run okay as they originally were, which suggests to me that MI will go on getting enums formatted the way it expects them. Will that work?

Chris


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