From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2600 invoked by alias); 25 Jun 2008 09:06:51 -0000 Received: (qmail 2589 invoked by uid 22791); 25 Jun 2008 09:06:50 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jun 2008 09:06:28 +0000 Received: (qmail 24041 invoked from network); 25 Jun 2008 09:06:26 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jun 2008 09:06:26 -0000 From: Vladimir Prus To: gdb@sources.redhat.com Subject: [MI] argv/argc/args Date: Wed, 25 Jun 2008 09:06:00 -0000 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806251306.27720.vladimir@codesourcery.com> 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 X-SW-Source: 2008-06/txt/msg00249.txt.bz2 In GDB 6.8 codebase, there were 3 different ways an MI command can be processed: 1. Sneaking via CLI directly (calling execute_command) 2. Calling a function, that takes argc/argv pair 3. Calling a function, that takes a string 'args' parameter with the raw part of MI command string after the command name. Some time ago, I've checked in a patch to remove (3), to clarify the code. Dan has raised concerns about backward compatibility, so here's an attempt to analyze the change afresh. The following is the complete list of command affected by my patch: -exec-run -exec-next -exec-next-instruction -exec-step -exec-step-instruction -exec-finish -exec-until -exec-return -exec-continue -exec-interrupt -target-download -target-select The trivial ones are: -exec-finish -exec-interrupt Those commands don't take any parameter at all, so no issues. The following commands are "easy": -exec-next -exec-next-instruction -exec-step -exec-step-instruction -exec-continue They are not documented to take any parameters. In practice, they will accept a parameter -- telling either the number of steps to perform, or the number of times to ignore a breakpoint we're stopped at. We'll have a problem here only if frontend indeed passes extra parameter, and that parameter is expression (not a simple number) and that expression has spaces. Seems to me this is unlikely. The bad ones are: -exec-until -target-download -target-select Those are documented to accept a parameter, and, furthermore, this parameter may contain spaces. So, if we strip quoting at MI level, we pass unquoted string futher. For example, -exec-until eventually calls until_break_command, which calls decode_line_1, and if we pass a filename with spaces to -exec-until and quotes are stripped before calling until_break_command, this will not work. The other two commands are even more risky. The gray ones are: -exec-run this is not documented to take a parameter but may. I think, though, that frontends probably use -exec-arguments, instead of relying on this undocumented behaviour. -exec-return This one is not documented as returning an expression -- this is probably a documentation bug. Frontend passing an argument to this command will be broken if it tries to pass an unquoted expression with spaces, which is probably not common. So, we have 3 commands for which requiring the input to be quoted per MI rules will cause issues; and fixing those issues will require changing other parts of GDB to avoid parsing filenames, which is risky at this point. It appears, that instead of reverting my original patch, we can just path those 3 commands via CLI directly. Does the plan sound reasonable? - Volodya