From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76708 invoked by alias); 9 Oct 2017 12:02:29 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 75953 invoked by uid 89); 9 Oct 2017 12:02:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Oct 2017 12:02:26 +0000 Received: from [10.0.0.11] (cable-192.222.251.162.electronicbox.net [192.222.251.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 9E21A1E055; Mon, 9 Oct 2017 08:02:24 -0400 (EDT) Subject: Re: Breakpoint commands in MI mode and "backtrace" To: Eli Zaretskii Cc: gdb@sourceware.org References: <8360bqt0im.fsf@gnu.org> <8a3d7153-7486-032f-aabc-6c3453f96459@simark.ca> <83shetsdg2.fsf@gnu.org> <83o9phs8zw.fsf@gnu.org> <83d15wsrvw.fsf@gnu.org> <83bmlgsqpm.fsf@gnu.org> From: Simon Marchi Message-ID: Date: Mon, 09 Oct 2017 12:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <83bmlgsqpm.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00029.txt.bz2 On 2017-10-09 03:52 AM, Eli Zaretskii wrote: >> Date: Mon, 09 Oct 2017 10:27:15 +0300 >> From: Eli Zaretskii >> CC: gdb@sourceware.org >> >>> Cc: gdb@sourceware.org >>> From: Simon Marchi >>> Date: Mon, 9 Oct 2017 00:16:28 -0400 >>> >>> Hmm, strange. It is a quite complex function being executed in the hookpost-backtrace. >>> Do you have any idea what line generates the error? It would be nice to have a >>> reproducer without having to build emacs... >> >> It's this line in xgetsysm: >> >> set $ptr = ((struct Lisp_Symbol *) ((char *)lispsym + $ptr)) >> >> where $ptr is a pointer to a Lisp_Symbol object: >> >> (gdb) p $ptr >> $2 = (struct Lisp_Symbol *) 0x17c9e38 >> >> and lispsym is an array: >> >> (gdb) ptype lispsym >> type = struct { >> struct Lisp_Symbol s; >> } [1298] >> >> Let me know if I can provide more information about this. > > Btw, with the patch, I get the same error if I invoke GDB in CLI mode. > > Thanks. > It's true that my patch seems to change how exceptions are handled, since safe_execute_command catches and prints exceptions. However, that expression does indeed seem erroenous, and I'm surprised GDB doesn't complain about it currently. How can you add a char* and a listp_Symbol*? Anyhow, can you try this patch here? It changes the uiout manually instead of going through safe_execute_command. diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c index f1db954a69..b08954132b 100644 --- a/gdb/cli/cli-script.c +++ b/gdb/cli/cli-script.c @@ -472,6 +472,8 @@ print_command_trace (const char *cmd) printf_filtered ("%s\n", cmd); } +static void restore_interp (void *arg); + enum command_control_type execute_control_command (struct command_line *cmd) { @@ -491,8 +493,17 @@ execute_control_command (struct command_line *cmd) { /* A simple command, execute it and return. */ std::string new_line = insert_user_defined_cmd_args (cmd->line); + + struct interp *old_interp = interp_set_temp (INTERP_CONSOLE); + struct cleanup *old_chain = make_cleanup (restore_interp, old_interp); + scoped_restore save_uiout + = make_scoped_restore (¤t_uiout, + current_interpreter ()->interp_ui_out ()); + execute_command (&new_line[0], 0); ret = cmd->control_type; + + do_cleanups (old_chain); break; }