>> > Does the size argument to the wp command refer to the size of a block of >> > memor > >Size of what's being watched. Maybe a bank of I/O registers, etc. > >Yes.
Ah, watching access to a bank of I/O registers is precisely what I am using my patched code for. Clearly the interpretation of the size argument is incorrect in the xscale implementation. > >> > y? I assumed it meant the size of a single access (byte, half-word, or >> > word). > >Or 8 bytes for floating point etc. Note that "single" access is tricky to >define, and that instructions like LDM/STM are not the only ones which >could be deemed to perform "multiple" access. Yes, I see. The xscale code ignores the size value (after merely verifying a value of 1, 2, or 4), so I extrapolated from the definition used by the bp command. Defining it as you describe makes the instruction generating the access irrelevant. (I wonder if the xscale debug hardware generates the debug exception on a dma access?) >The "size" for BP is problematic. Not all Thumb instructions are 2 bytes, >not all ARM ones are 4 bytes. Hmm, I could see how these situations could cause problems with software breakpoints. Nonetheless, for software breakpoints, the size argument is really just specifying the mode the processor is running in (please correct me if I'm wrong). The xscale bp code uses it to determine whether to use the arm or thumb variant of the bkpt instruction. To interpret size of software breakpoints the same as for hardware breakpoints, you would need to fill a region of memory with bkpt instructions, after saving the original contents. And you would still need to know the processor mode. Has this been done or discussed? Seems impractical. And modes could be mixed within a region. >On the other hand, "trigger watch/break point on data/code access inside >this region" is straightforward semantics, which matches hardware well. Yes, makes sense. To summarize my understanding of the size argument to wp/bp: - wp: size of memory region, starting from the specified address - bp: software: 2=thumb mode, 4=arm mode; hardware: same as for wp The above subject to the limitations of the target's debug hardware, of course (xscale debug hardware only supports hardware breakpoints on a single address). Unless you tell me I still don't get it, I'll try to get around to patching xscale wp code to interpret size correctly. Maybe clarify the explanation in the User's Guide as well. Thanks much, Gents! Mike ---- _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
