Kgdb doesn't work with THUMB2 kernel

[fhgwright]

When the kernel is built with KGDB support and in the default THUMB2 mode, then attempting to enter kgdb (via SysRq) results in an error of the form:

  SysRq : DEBUG
  Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2

This is due to missing support for 16-bit breakpoint instructions.

I found an old unmerged patch on a mailing list that corrects this. Although it no longer applied verbatim, I updated it for the 3.8 kernel, and it now works. It also appears to apply cleanly to 4.4 and 4.9, though I haven't actually tested it with those kernels.

The fix really belongs in mainline, but getting it into this repo is better than nothing.

I submitted a pull request for the 3.8 version of the fix.

[fhgwright]

Pull request here:

#132

[fhgwright]

I could submit PRs for the 4.4 and 4.9 versions of this patch, or you could just cherry-pick the 3.8 commit as is (which is all I did to create them).

[RobertCNelson]

i'll merge them into v4.4.x-ti/v4.9.x-ti, but those have thumb2 disabled. we pull in ti's cmem module, for opencl support on the x15, it doesn't like to be built against a thumb2 enabled kernel in it's current form..

Regards,

[fhgwright]

Ah, OK. It does make sense to have the fix in place in case THUMB2 becomes usable in the future.

I was puzzled by how this bug could have survived so long, and one thing I suspected is that people using kgdb just turned off THUMB2, either as a workaround, or for some other reason.

I also wondered whether turning off THUMB2 would make sense in general, if one isn't too concerned about the memory footprint, but from what I've read, the performance cost of THUMB2 vs. ARM native is small enough that it does make sense to use THUMB2 for at least most of the code, perhaps with a few critical pieces in ARM native. But that assumes that one can do a "mixed architecture" build, which may have issues. Then again, the ability to run i386 code in an X86_64 kernel is probably a form of "mixed architecture", so maybe there's hope. If so, that might also be a solution for the opencl problem.