Re: [patch] Add support for ARMv7M devices.

[Jonathan Larmour <jifl at eCosCentric dot com>]

On 01/11/10 03:39, Daniel Jacobowitz wrote:
> On Sat, Oct 30, 2010 at 12:46:53AM +0100, Jonathan Larmour wrote:
>> I'm not quite sure what you mean by this since the xpsr and cpsr are given
>> the same register number so I thought that what happens at the remote
>> protocol level would be the same?
> 
> The T bit is in a different place.  There's at least one existing stub
> which fakes a "CPSR" register when debugging Cortex-M devices with an
> XPSR, and moves the T bit to a different place.

Oh, I see. Presumably to work around the absence of this patch!

> Are your stubs returning FPA registers and a fake CPSR, or are they
> returning FPA registers and an XPSR?  Both are pretty wonky.

FPA registers and an XPSR. Because up to this patch (so including GDB 7.2)
the FPA registers were expected by GDB by default. We and others just
complied with GDB's requirements.

>>>  If it's
>>> really necessary, we can try to auto-detect that case in the remote
>>> protocol, but really this is what the XML register descriptions are
>>> for.
>>
>> It does create a problem for me at least because we have existing GDB
>> stubs implementations programmed into flash on Cortex-M targets (it's hard
>> to do anything else but program into flash with these small chips). So CVS
>> GDB (and presumably GDB 7.3+) will no longer work with these
>> targets.
> 
> Sure it will.

Well, it won't work "out of the box".

> You can override this by providing an appropriate XML
> file to GDB via set tdesc filename (barring discussion, above, of the
> T bit).  One which matches your stub.

Alas, this isn't so easy for GUI users, including Eclipse users.

> Or, you can implement the auto-detection somehow; GDB has
> infrastructure for that in general, but this case is a bit peculiar.
> I don't know enough about what your stub returns to say for sure.

Ah, I thought you had already got an idea for how auto-detection would work.

>> I also wonder about any JTAG debuggers which support Cortex-M (e.g.
>> Ronetix PEEDI).
> 
> I do not have access to any debugger which supports Cortex-M and the
> GDB protocol but not XML, sorry.  Someone who does needs to figure out
> what they do.

I was able to try a PEEDI on a Cortex-M board today. It definitely does
not support XML-based target descriptions in general. I'd be amazed if it
was alone. I can confirm that everything appears ok if I do provide an
appropriate target description using "set tdesc ...".

I do understand that Cortex-M (or anything marked as EABI) doesn't have
FPA registers, but nor have most ARM cores for a long time. There are
quite a number of JTAG models out there which claim to support Cortex-M
with GDB. Given what this patch adds, none of them would support returning
the correct target description (it would have to reference
"org.gnu.gdb.arm.m-profile" so that gdbarch->is_m gets set, but that
feature is only added in this patch).

I think there's a more general issue here about whether it's expected to
maintain support for existing working stub implementations such that they
can be used as they have been used even when GDB is upgraded. Changing the
interface with GDB remote stubs used to be a big no-no for GDB. But is it
now the case with the target description support that it's considered
acceptable to break compatibility with _existing_ stubs as long as a
target description file can fix it back up again? I think some users would
struggle working out what the cause of failures like "Remote 'g' packet
reply is too long" is, nevermind how to fix this after starting to use a
newer GDB.

If this is the policy then that's fine, as long as people understand that.
If it's not, then the FPA regs (even though unused in EABI) perhaps ought
to go back in. No matter what I can deal with my own GDB stub whatever is
decided; I'm a bit more concerned about the JTAG debuggers. I'm fully
expecting you to tell me that this is the policy now and the JTAG
manufacturers will have to work out how to update customers in the field,
but I'd like to know for definite.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine