On Monday 02 November 2009, Øyvind Harboe wrote:
> While the attached patch tightens things up, I don't think we've
> solved it just yet...
Looking more closely, this patch intoduced *TWO* bugs:
- The one causing the big regression, swapping physical
and virtual addresses for the work area:
if (mmu active)
use physical address
else
use virtual address
- Changing the behavior of "-work-area-virt 0" from the
previous "re-specify the default" to "actually use a
mapping that's set up at address zero".
Now, the first bug got fixed with a cleanup patch. (Leaving
aside issues like *which* MMU context has that mapping...)
But fixing the second bug requires changing *EVERY* config file
which blindly specified "-work-area-virt 0", trusting that
it was a safe default. Not yet fixed...
I can't quite see reverting that change; it's the right idea,
just the timing was bad.
Config files for no-mmu targets, easy: they're obviously
wrong to specify any virtual address whatever. But that's
another symptom of flaky MMU handling ... on no-mmu targets,
specifying such addresses should at least trigger warnings!
But for targets with MMUs ... it's remotely possible that
some configurations really *did* map memory at zero. Mostly
that's kept invalid, so dereferencing NULL triggers a hardware
error of some flavor.
I'm going to just remove all "-work-area-virt 0" stuff, and
folk working with oddball MMU configurations can submit
patches for them -- later.
- Dave
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
