Hi,
Passing Christopher Head's reply[1] here for the sake of visibility,
with my comments inline.
On Fri, Apr 10, 2015 at 12:12:52AM +0300, Paul Fertser wrote:
>> My idea is that we should first agree on how it should be done
>> properly, then try to implement it; current patches we have on
>> Gerrit, are not cutting it at all, AFAICT.
>
> Paul, sorry, I am not on the mailing list. I have a few comments
> about the message you linked to: how do you differentiate between
> “small” and “large” memory accesses? It seems like this could cause
> confusion.
What seems to be the natural thing to do here is to call
target_{read,write}_buffer "large" memory access and everything else
small. This way when you use load_image or dump_image or gdb "load"
you'll get "large" access automatically.
> I imagine one is mostly interacting with the device through GDB. If
> I print an integer, that’s small, right? What if I print a
> twenty-character string? A kilobyte-long complicated struct? Why
> then do some of these behave differently to others?
I think kilobyte-long string would still be considered "small". I
proposed the distinction solely for the sake of optimising image
loading and dumping.
> I am not actually sure how GDB behaves when debugging a non-coherent
> SMP target normally, or what people expect; I’m afraid 100% of my
> SMP experience is on x86, and in terms of using GDB, all in
> userspace. It seems to me that maybe when writing to RAM you should
> always invalidate other cores’ D-caches.
Well, I can't agree here for the reasons and rationale outlined in the
first mail. I personally would expect the behaviour I described, but
that's just me, probably the other opinion is overwhelming and so my
point is moot. But we need to get all the opinions first to come to
agreement.
> However, there is one more point: when writing data to RAM that is
> smaller than a cache line, don’t you want to clean all cores’
> D-caches first, and isn’t this perhaps even true for APB access?
> Otherwise, if you write to one area of a cache line, you will throw
> in the garbage a write that some core did to a different area of the
> same cache line, which is bad! Maybe you could argue it’s not all
> that bad if core 1 did the write and you are doing your debug write
> while debugging core 2, because that reflects what would happen if
> core 2 did a write of its own (I guess? I am not certain), but even
> then I would argue that debugging is special and ought to be exempt
> from such requirements—in other words, *normal firmware* would be
> required to precisely obey cache rules in order to operate across
> cores properly, but interactive work in a debugger ought to be a bit
> more user-friendly.
I'm afraid such user-friendliness might cause more confusion than
actual help.
The problem of cleaning (and it can happen automatically during
runtime by cache eviction) a partial cache line is of course bad, but
it's not any better when your firmware is not prepared to handle
it. Hiding issues like that to be more friendly during debugging seems
to be a wrong way to aid the developer here. Of course, there need to
be commands to allow arbitrary cache operations during debug by
_explicit_ user actions. But that should be about it, IMHO.
[1] http://openocd.zylin.com/#/c/2429/
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[email protected]
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
