From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] target read/write partial
Date: Wed, 15 Oct 2003 23:12:00 -0000 [thread overview]
Message-ID: <20031015231244.GA30203@nevyn.them.org> (raw)
In-Reply-To: <3F8DD39C.4090007@redhat.com>
On Wed, Oct 15, 2003 at 07:09:16PM -0400, Andrew Cagney wrote:
> >On Wed, Oct 15, 2003 at 06:16:28PM -0400, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>This patch adds target read/write partial methods.
> >>
> >>It's almost ready for prime time. I want to first see through some
> >>other target cleanups namely:
> >>+ /* FIXME: cagney/2003-10-15: This code should walk down the target
> >>+ stack looking for a stratum that supports the mechanism.
> >>+ Unfortunatly, there isn't a per-target-stack chain to walk round.
> >>+ Catch-22. */
> >>and a s/target_ops/target/ transformation.
> >
> >
> >Preferably not target - didn't someone suggest gdbtarg? Or maybe
> >gdb_target.
>
> ... you mean someone actually likes gdbtarg :-)
Not all that much. But I really dislike "target".
> >>Note that it includes:
> >>+ /* Transfer up-to LEN bytes of memory starting at OFFSET. */
> >>+ TARGET_OBJECT_MEMORY
> >>I'm going to need that when implementing a per-target
> >>CONVERT_FROM_FUNC_PTR_ADDR.
> >
> >
> >How is that different from a memory read, which we've already got? I am
> >guessing that it's because you want to support partial memory
> >operations (avoid packet size limits), but you never explained your
> >goal.
>
> I previously wrote:
>
> >In the light of Joel's "upload/download" commands, and lessons (gdb/589)
> >learn't from similar interfaces, and a realization that I need this for
> >memory:
> ...
> >- it takes an explicit target vector
> >- there are both read and write variants (instead of query)
> >- it, what the heck, takes a LONGEST
> >- it makes the fact that the method isn't expected to perform a full
> >transfer explicit
>
> gdb/589 is yet another example of how the existing code always did
> partial xfers, yet no one noticed. Have a look at how many levels of
> GDB code try to locally solve the partial transfer problem when
> generic_load is called.
>
> The only significant difference is the addition of an explicit target
> vector. But that's really significant. I should probably comment out
> TARGET_OBJECT_MEMORY until a target implements it.
Yes, please. Anyway, I see where you're going now.
> >>+ /* Map pre-existing objects onto letters. DO NOT do this for new
> >>+ objects!!! Instead specify new query packets. */
> >
> >
> >Could that be a little clearer - I had to read the code a couple of
> >times to figure out what you meant. I guess you just want to say that
> >there's no need to use single letters?
>
> The code abuses:
>
> <letter> + <annex>
>
> as a way of generating packets. The entire qK* and qR* packet maps have
> been kidnapped by this. The un-approved RedBoot patches did the same
> with qM*.
>
> I'll expand the comment.
Do we need a standard terminator here too - colon or semicolon again?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-10-15 23:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-15 22:16 Andrew Cagney
2003-10-15 22:32 ` Daniel Jacobowitz
2003-10-15 23:09 ` Andrew Cagney
2003-10-15 23:12 ` Daniel Jacobowitz [this message]
2003-10-17 18:05 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031015231244.GA30203@nevyn.them.org \
--to=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox