Hi Ulrich,
> I've now got it working reliably on on Versatile Express, after fixing
> a couple of bugs on the GDB side (both in the HW-watchpoint patch, and
> in common GDB code). The testsuite now passes with no regressions when
> enabling HW watchpoints, except for two tests that require more than one
> single watchpoint to be supported.
That's good to hear, thanks.
> This raises another couple of issues/questions, however:
>
> - In testing on Versatile Express, I noticed what appears to be SMP
> related bugs in handling regular software breakpoints: occasionally,
> software breakpoints simply are not hit and execution continues as if
> the underlying code had not been changed at all. This symptom
> completely goes away if GDB and the debugged process are forced to
> the same CPU using the affinity feature (e.g. with schedtool).
I've seen this issue in the past but I thought I'd fixed it. What kernel are
you using and do you have CONFIG_ARM_ERRATA_720789 enabled?
> My guess, just from seeing those symptoms, would be that when inserting
> a software breakpoint via ptrace, not all i-caches on all CPUs are
> reliably flushed ... Any thoughts on this?
There was an I-cache aliasing problem in the kernel coupled with a TLB
invalidation hardware bug on the versatile express. I fixed these though
and haven't seen any problems since.
> - As mentioned above, the kernel currently only supports one single
> watchpoint to be active at a time, even though hardware might support
> multiple ones. The reason seems to be that when a watchpoint triggers,
> the kernel cannot figure out which one it was (if there's more than one
> choice).
>
> This is a bit unfortunate, given that GDB will attempt to insert two
> or more watchpoints in many interesting cases (e.g. a "watch *p"
> command will insert *two* low-level watchpoints, one at the address
> of p, and one at the address where p (currently) points to).
>
> In addition, for regular (write) watchpoints, GDB does not actually
> *require* the underlying hardware/kernel to specify which watchpoint
> was hit; GDB is able to find out by itself by checking whether the
> values at any of the currently active locations actually changed.
> (For read/access type watchpoints, GDB does require that underlying
> support -- but those are much more rarely used anyway.)
>
> Do you see any chance of improving upon the current behaviour?
Hmmm, I'll need to have a think about this. What does GDB do if it receives
a SIGTRAP with si_addr set to (potentially) complete nonsense? As an aside,
Cortex-A15 reports the faulting address for a watchpoint correctly, so we
will be able to use multiple watchpoints there.
> - Finally, I noticed when reading kernel code that under some
> circumstances, the kernel will automatically do a single step to
> get off a watchpoint that was just hit. However, this does not
> happen for user-space watchpoints installed via ptrace, right?
> (Just wanting to confirm; since GDB currently does that single
> step itself -- we don't want *both* kernel and GDB to issue a
> single step each ...)
If the {break,watch}point has been inserted via ptrace, the kernel will
send a SIGTRAP instead of stepping the instruction.
> I haven't gotten to looking further into other hardware (IGEP,
> Panda) -- that's next on the list.
Good stuff, keep me posted if you see any further problems!
Thanks,
Will
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
