This is the mail archive of the gdb@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: Memory-mapped peripheral registers, remote protocol and memory maps


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


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