From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4528 invoked by alias); 14 Oct 2013 09:38:41 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 4514 invoked by uid 89); 14 Oct 2013 09:38:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,TRACKER_ID autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <525BBB9C.2030006@redhat.com> Date: Mon, 14 Oct 2013 09:38:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: archer@sourceware.org CC: tromey@redhat.com, jan.kratochvil@redhat.com Subject: tromey/python non-trivial merge notification Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q4/txt/msg00000.txt.bz2 Jan asked me to investigate a non-trivial merge issue today with the tromey/python branch. I merged tromey/python and fixed the trivial merge conflicts first. The commit reference for that is: aed684a9a6f3dab80262ca21d6c728e99526b37f The non trivial issue was as follows: Upstream GDB added a patch that caused some conflict in the gdb.cli() Python command. The commit was: d03f62382e0502a42020e6379dbe3c9252813c65 2013-09-06 Andrew Burgess * cli/cli-interp.c (_initialize_cli_interp): Add a command_loop_proc to interp_procs. * event-top.c (cli_command_loop): Change signature to match interp_command_loop_ftype. * event-top.h (cli_command_loop): Same. * interps.c (interp_new): Require every interpreter to have a command_loop_proc. (current_interp_command_loop): Just call the command_loop_proc on the current interpreter. * tui/tui-interp.c (_initialize_tui_interp): Add a command_loop_proc to interp_procs. The first fix I thought of was just to pass cli_command_loop a NULL (as cli_command_loop does not actually do anything with the data). Jan rightly pointed out that in the future this may cause issues as, really, this code requires a command_loop_proc. Then we thought about using current_interp_command_loop instead. This would work fine, but it would be MI incompatible. I could not think of a reason why gdb.cli() would be invoked from MI. (It does not make a whole lot of sense to do so, but someone might prove me wrong ;) ) I decided to bar invocation of this command in MI, and just use current_interp_command_loop instead. The commit for this fix is: 269d883cd0c2fd8a51163e4472963b1b5a9a576e 2013-10-14 Phil Muldoon * python/python.c (gdbpy_cli): Use current_interp_command_loop and bar invocation from MI. As this is a non-trivial change I decide to notify archer list about the changes. Cheers, Phil