This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] Correct semantics of target_read_partial, add target_read_whole


Daniel Jacobowitz wrote:

> On Thu, Jun 22, 2006 at 08:24:54PM +0200, Mark Kettenis wrote:
>> > Date: Wed, 21 Jun 2006 23:23:55 -0400
>> > From: Daniel Jacobowitz <drow@false.org>
>> > 
>> > Originally, target_read_partial was supposed to read "however much it
>> > could manage to" and then higher level functions were supposed to
>> > handle the rest. But every existing implementation always reads enough
>> > data in its first call; the one remote protocol implementation did so
>> > by issuing as many packets as necessary, which defeated the point of
>> > the original design.
>> 
>> Ah, it all makes sense to me now.  I'm wondering whether we should
>> "export" target_read_partial() (and target_write_partial()) at all.
>> It's never right to use them except for implementing higher-level
>> target read/write functions isn't it?
> 
> There's some messiness in kod.c.  But didn't we decide that was on the
> chopping block to be removed?  Other than that, in my current working
> tree there are absolutely no calls to these functions outside of
> target.c.  So I think you're right: we can stop exporting them at all.

There are also target_write_memory_partial and target_read_memory_partial.

The write variant is used only for implementation for the 'load' command. My
work on implementing flash support will hopefully kill that use.

The read variant is used in MI implementation of read, where, guess what,
it's wrapped in a loop. I'll add replacing that loop with
target_read_memory to my todo.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]