public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: <Paul_Koning@Dell.com>
To: <jon@beniston.com>
Cc: <yao@codesourcery.com>, <gdb@sourceware.org>
Subject: Re: Memory-mapped peripheral registers, remote protocol and memory maps
Date: Thu, 29 Nov 2012 17:23:00 -0000	[thread overview]
Message-ID: <C75A84166056C94F84D238A44AF9F6AD2BAC5B@AUSX10MPC103.AMER.DELL.COM> (raw)
In-Reply-To: <009401cdce4f$03913a80$0ab3af80$@beniston.com>


On Nov 29, 2012, at 11:31 AM, Jon Beniston wrote:

>> The following command 'p' will only generate 'm' packet with the right size.
>> 
>> (gdb) p *(unsigned int *) 0x8048608
>> Sending packet: $m8048608,4#3f...Packet received: 5589e583
>> 
>> 
>> (gdb) p *(char *) 0x8048608
>> Sending packet: $m8048608,1#3c...Packet received: 55
>> 
>> I admit they are tricky.
> 
> Yes, this is fine from the command line, but ideally I would like something that works when GDB is being driven by a GUI such as Eclipse, which may not necessarily know the correct size to use. It does work in some cases, but not all (i.e. when dumping memory).

If so, that would be the GUI's issue.  If GDB can be told what to do -- which appears to be the case -- then it's up to whoever does the telling to tell correctly.  If GDB can do it but you ask it the wrong thing, it will obey and do the wrong thing.  So don't do that.

What's not clear to me is whether there is a *guarantee* that certain UI requests will produce certain "m" packets.  Clearly there are a bunch of things that fall out of the current implementation, but if somehow the implementation were to change and, say, that "p" command above is split into two m packets, what then?  By the current remote protocol specification, such a change would be legal.  Not terribly rational perhaps, but legal.

For reliable access to memory mapped device registers, you'd need to have a guarantee.  For example: "A request for 1, 2, 4, or 8 bytes with a p or x command, where the memory address is naturally aligned, will always become a single remote protocol memory read of that same size.  For other transfer sizes and alignments, the request may or may not be split into pieces, and the behavior for those is subject to change."

Clearly you can propose any number of rules, but for starters you'd need a documented rule so that users know what they can count on and implementers know what they are required to preserve.

	paul

  reply	other threads:[~2012-11-29 17:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-28 19:24 Jon Beniston
2012-11-29  9:16 ` Yao Qi
2012-11-29 11:23   ` Jon Beniston
2012-11-29 15:51     ` Yao Qi
2012-11-29 16:32   ` Jon Beniston
2012-11-29 17:23     ` Paul_Koning [this message]
2012-11-29 17:57       ` Jon Beniston

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=C75A84166056C94F84D238A44AF9F6AD2BAC5B@AUSX10MPC103.AMER.DELL.COM \
    --to=paul_koning@dell.com \
    --cc=gdb@sourceware.org \
    --cc=jon@beniston.com \
    --cc=yao@codesourcery.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).