From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32471 invoked by alias); 22 Aug 2014 22:08:02 -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 32455 invoked by uid 89); 22 Aug 2014 22:08:01 -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; Fri, 22 Aug 2014 22:07:59 +0000 Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MM7uOx018025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Aug 2014 18:07:56 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7MM7uOx018025 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7MM7uOx018025 Received: from mailsyshubprd04.lss.emc.com (mailsyshubprd04.lss.emc.com [10.253.24.26]) by maildlpprd53.lss.emc.com (RSA Interceptor) for ; Fri, 22 Aug 2014 18:07:36 -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 s7MM7cfN023086 for ; Fri, 22 Aug 2014 18:07:39 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 2AFDB5D1550; Fri, 22 Aug 2014 18:07:38 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 271AE5CFD03 for ; Fri, 22 Aug 2014 18:07:38 -0400 (EDT) To: "gdb@sourceware.org" Subject: Re: possible gdb agent expression extension In-reply-to: <20426.1406558341@usendtaylorx2l> References: <20426.1406558341@usendtaylorx2l> Comments: In-reply-to David Taylor message dated "Mon, 28 Jul 2014 10:39:01 -0400." Date: Fri, 22 Aug 2014 22:08:00 -0000 Message-ID: <12648.1408745258@usendtaylorx2l> From: David Taylor X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd53.lss.emc.com X-SW-Source: 2014-08/txt/msg00116.txt.bz2 David Taylor wrote: > 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. I never saw any responses to this. My inclination is to make setmem like const and ref and have 4 versions one each for 8, 16, 32, and 64 bits -- though I could be persuaded that there should be just one which takes the bit size as an argument. Hopefully the markup is correct: @item @code{setmem8} (0x??): @var{addr} @var{value} @result{} @item @code{setmem16} (0x??): @var{addr} @var{value} @result{} @item @code{setmem32} (0x??): @var{addr} @var{value} @result{} @item @code{setmem64} (0x??): @var{addr} @var{value} @result{} Pop an address @var{addr} and a value @{value} from the stack. For bytecode @code{setmem}@var{n}, set the @var{n}-bit value at @var{addr} to the least significant @var{n}-bits of @var{value}. Ignoring architecture pointer alignment issues, it is as if the operation *@code{uint}@var{n}@code{_t}@var{addr} = @code{uint}@var{n}@code{_t}@var{value} What I'm trying to say is: setmem8 (0x??): ==> setmem16 (0x??): ==> setmem32 (0x??): ==> setmem64 (0x??): ==> Pop an address and a value from the stack. For bytecode setmem, set the -bit value at to the least significant -bits of . Ignoring architecture pointer alignment issues, it is as if the operation *(uint_t *)addr = (uint_t) was performed. If attempting to set memory address to would cause a processor exception, terminate with an error. Similarly, for setreg: @item @code{setreg} (0x??) @var{regnum}: @var{value} @result{{} Or: setreg (0x??) : ==> Pop off the stack and set to . If register does not exist or cannot be set, terminate with an error. is a 16 bit value with the same interpretation as for the reg operation. Looking at gdb/common/ax.def, the last opcode that appears to be allocated is 0x34 for printf. So, how about opcodes: 0x35 for setmem8 0x36 for setmem16 0x37 for setmem32 0x38 for setmem64 0x39 for setreg ? Also, should there be a string to place within the qSupported response to tell GDB that these operations are supported? Maybe: SetOps+ ? Or something else? David -- dtaylor at emc dot com