Re: remote/2158: Memory access error while loading section .text,Escape characters

[Ronald Hecht <ronald dot hecht at uni-rostock dot de>]

The following reply was made to PR remote/2158; it has been noted by GNATS.

From: Ronald Hecht <ronald.hecht@uni-rostock.de>
To: Cc: gdb-gnats@sources.redhat.com
Subject: Re: remote/2158: Memory access error while loading section .text,
 Escape characters
Date: Fri, 18 Aug 2006 09:43:44 +0200

 Daniel Jacobowitz wrote:
 
 > On Thu, Aug 17, 2006 at 03:58:27PM +0200, Ronald Hecht wrote:
 >  
 >
 > What on earth is going on?  Maybe, are you working on a target with
 > only about 12-16 bytes of registers in the 'g' packet?  GDB
 > should be performing _much_ larger writes than this.
 >
 >  
 >
 
 The target is an extremely simple 8-Bit processor, with just one accu 
 and an additional index register. The processor is only for educational 
 purposes: http://www-md.e-technik.uni-rostock.de/lehre/vlsi_i/proc8/
 
 >> Sending packet: $X16,a:@\001\001@\000"\000!\020\000#5b...Ack
 >> Packet received: OK
 >> Sending packet: $X20,0:#50...Ack
 >> Packet received: OK
 >> Sending packet: $X20,0:#50...Ack
 >> Packet received: OK
 >>   
 >
 >
 > This is the problem.  It's rounded down to zero.  OK, that's easy to
 > fix.  Could you try the attached patch?
 >
 >  
 >
 This actually works.
 
 >> Transfer rate: 4451 bits/sec, 9 bytes/write.
 >>   
 >
 >
 > This should be much bigger.  If this is really triggered by a small
 > register set, you might want to add a qSupported response telling
 > GDB that larger packets are safe; see a recent version of the manual.
 >
 >  
 >
 
 The speed is extremely volatile. I think because of the small size. Now 
 I'm getting
 
 
 Loading section .text, size 0x45 lma 0x0
 Start address 0x0, load size 69
 Transfer rate: 61333 bits/sec, 9 bytes/write.
 
 >> It returns 20.
 >>   
 >
 >
 > Nine or ten of which are going to the packet header, and the rest to
 > data.
 >
 > You're right that this block of code isn't necessary, by the way - it's
 > supposed to be an optimization for targets where misaligned writes are
 > slow.
 >
 >  
 >
 
 Thanks for the patch
 Ronald