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 11/29/2012 07:22 PM, Jon Beniston wrote:
In some cases, there might be a large variety of inter-mixed
8/16/32-bit registers, which you might not have the space to cater
for in a small stub. Can we be sure that GDB will only generate a 'm
0x0x00d000 4' packet? It would be tricky for a stub to deal with a

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.

packet of a larger size (say if the register area is opened in a
memory viewer). Also, it would be nice to prevent reads from certain
addresses, in case they have side effects (i.e FIFOs, etc).


Something similar was done in codesourcery (by other people) to handle memory-mapped register and side effect of reading registers (we call it read sensitiveness, IIRC). The target description mechanism
(http://sourceware.org/gdb/current/onlinedocs/gdb/Target-Descriptions.html) was enhanced, in which the name, width, mapped address and read sensitiveness of each register is described. With these knowledge, GDB can take care of memory-mapped register. However, these patches didn't go to upstream.


--
Yao (éå)


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