From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15239 invoked by alias); 19 Jul 2002 12:34:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15232 invoked from network); 19 Jul 2002 12:34:29 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 19 Jul 2002 12:34:29 -0000 Received: from dsl254-114-118.nyc1.dsl.speakeasy.net ([216.254.114.118] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17VWxo-0002JT-00; Fri, 19 Jul 2002 07:34:28 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17VWxt-0006ag-00; Fri, 19 Jul 2002 08:34:33 -0400 Date: Fri, 19 Jul 2002 05:34:00 -0000 From: Daniel Jacobowitz To: Alexei Minayev Cc: gdb@sources.redhat.com Subject: Re: gdb-h8-stub Message-ID: <20020719123433.GA25272@nevyn.them.org> Mail-Followup-To: Alexei Minayev , gdb@sources.redhat.com References: <20020718200542.GB13992@nevyn.them.org> <20020719060019.54178.qmail@web13509.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020719060019.54178.qmail@web13509.mail.yahoo.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-07/txt/msg00197.txt.bz2 On Thu, Jul 18, 2002 at 11:00:19PM -0700, Alexei Minayev wrote: > Hi Daniel, > > thanks for an interesting discussion. > > --- Daniel Jacobowitz wrote: > > On Thu, Jul 18, 2002 at 11:25:50AM -0700, Alexei Minayev wrote: > > > X200000 > > > M0,15:... ; (this would actually mean 0x200000 to 0x200015) > > > M15,15:... > > > M30,15:... > > > ... > > > > > > So according to this, the stub *must* read the address from the X command > and > > > store it for future memory operations, even if it doesn't support binary > > > downloads. > > > In your opinion, is that what gdb means? > > > > No, what I'm trying to say is that that's the wrong behavior for the > > client. You'll need to figure out why GDB is doing this. > > > it might have been the wrong behavior for the client... but it's a very > standard client code, working in many stubs. > The stub code, in particular, when parsing an 'M' command, is looking for an > *absolute* address. But the gdb sends relative addresses to him. > I mean, what could the client possibly say wrong, that gdb chooses a totally > different way of communication? > > I went ahead and implemented binary downloading. > Still: > X200000,0...Ack > X0,4e...Ack (I'd expect X200000,4e here) > Packet received: OK > X4e,4e...Ack (expected: X20004e,4e) > Packet received: OK > and so on. > > Address is *relative* to what comes in the first packet. E.g. the second > packet gdb sends is "X0", which means "0 bytes +0x200000 base", and the base > value was in the first packet. > > Am I forgetting some option or variable? The test for the X packet is missing something that is present in normal use: memaddr = remote_address_masked (memaddr); p += hexnumstr (p, (ULONGEST) memaddr); *p++ = ','; You have TARGET_ADDR_BIT set too small for your port. You are probably confusing TARGET_PTR_BIT (the number of bits in a pointer, which can have some separate space marker not included in this count) and TARGET_ADDR_BIT (the number of bits to correctly identify an address when dealing with the OS or stub). -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer