From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29051 invoked by alias); 28 Jul 2014 14:39:28 -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 29038 invoked by uid 89); 28 Jul 2014 14:39:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_DNS_FOR_FROM,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailuogwdur.emc.com Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 28 Jul 2014 14:39:26 +0000 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6SEdMBv010964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jul 2014 10:39:24 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s6SEdMBv010964 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s6SEdMBv010964 Received: from mailsyshubprd04.lss.emc.com (mailsyshubprd04.lss.emc.com [10.253.24.26]) by maildlpprd55.lss.emc.com (RSA Interceptor) for ; Mon, 28 Jul 2014 10:39:04 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailsyshubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6SEd3in030903 for ; Mon, 28 Jul 2014 10:39:04 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 7CE515D08A6; Mon, 28 Jul 2014 10:39:01 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id E4A595CF351 for ; Mon, 28 Jul 2014 10:39:01 -0400 (EDT) From: David Taylor To: "gdb@sourceware.org" Subject: possible gdb agent expression extension Date: Mon, 28 Jul 2014 14:39:00 -0000 Message-ID: <20426.1406558341@usendtaylorx2l> X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd52.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00029.txt.bz2 We're thinking of extending gdb agent expreswions by adding additional bytecodes. Before doing this I'd like to determine whether the idea of doing this would be looked upon favorably and what form it should take. [One of our current goals with regard to GDB is to use stock GDB sources as much as possible and to only make changes that are either bug fixes or extensions that when contributed back are likely to be looked upon favorably in concept and hopefully in implementation.] We would like to be able to set variables using byte code expressions. In practice this means being able to set memory and being able to set registers. There are no byte code for either of these. For setting registers, a new opcode 'setreg'. Like 'reg' the next two bytes of the bytecode stream are the register number. Top of expression stack is the value to set it to. And the top of the expression stack is popped. For setting memory, two possibilities come to mind: . either, one opcode 'set' or 'setmem' with next byte in byte code stream saying how big a chunk of memory to set, with top two values on expression stack being the address to set and the value to set it to. . or, four new opcodes (similar to 'ref' and 'const') -- set8, set16, set32, and set64 with, again, top two values on expression stack being the address to set and the value to set it to. Is this something people would like to see added? Which approach do people feel is better? Which should be top of stack? Address? Or value? And should they be popped? As I have other, higher priority, items to work on, it will likely be awhile before I start on this.