[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468

--- Comment #37 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-18 00:41:10 GMT ---
(In reply to comment #36)
> 
> I tried GDB-7.4.50.20120316 that I assume contains this patch. Two issues:

I wouldn't recommend using a random day's snapshot. I'd recommend using a
stable release with the patch applied. Hence having problems like build errors.

> 2. Support for VFP as the one found on Cortex-M4F appears to be missing (from
> what I see in gdb/features). Cortex-M4F has vfpv4-sp-d16: VFP version 4, single
> precision with 16 d registers. Note: There is vfpv2 that presents 16 d
> registers but it is not quite adequate as Cortex-M4F 16 d registers are at the
> same time 32 s (single precision) registers.

The single precision registers are just virtual halves of the double registers.
Look at the use of vfp_pseudos in arm-tdep.c. From what I can see they should
spring into existence automatically as pseudo-regs if there are d registers in
the target description, and no s registers defined (specifically GDB checks
there is no "s0"). So in theory I would expect vfp2 to be a close match.

However in practice it appears that's probably not going to help much. I
thought GDB was indeed meant to be doing the right thing based on what
registers it sees, but it looks like what VFP work there has been in public GDB
has been oriented around native Linux, and so anything VFP-related will not be
available for us. Sigh. In any case, I notice even the VFP support there refers
to cpsr, not xpsr, which is not ideal (even though it's only a name).

So it looks like we need a further patch for GDB to add the Cortex-M4 register
set after all :-/. Otherwise it will make life much for confusing for our
users, and much more awkward for anyone trying to use eCos with Eclipse
(eCosCentric would be all right because we spin our own tools anyway for
eCosPro, so if we needed this support we would just go ahead and add it, but I
don't see why eCos users should be at a disadvantage).

The easiest approach is probably a further extension of the register guessing.

> Considering the said above, my proposal is: At present continue with GDB as-is
> and define time-frame (2-4 week) for next milestone that would be either GDB
> 7.3 with backport of the patch or GDB 7.4 - in both cases with addition of
> Cortex-M FPU profile.

I don't have a way to test what you're doing, but I will attach an untested
patch which I believe should work. This is on top of the earlier patch. Let me
know how you get on with it. Once we're happy the patch works, I can get it
into upstream GDB.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.