[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 #36 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-16 16:08:58 GMT ---
(In reply to comment #35)
> (In reply to comment #34)
> > (In reply to comment #33)
> > > (In reply to comment #32)
> > > > (In reply to comment #31)
> > > > > 
> 
> [snip]
> 
> > You just have to make sure you have made the necessary changes in the stub so
> > that when VFP is used, it sends the registers in the format GDB expects. i.e.:
> > 
> 
> I am going to open a bug on Cortex-M FPU architecture and put my questions
> there.
> 
> [snip]
> 
> > > To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
> > > for the time being to go with GDB as-is (or with work-around) and gain some
> > > time for Jifl's patch + VFP support.
> > 
> > The version of the patch referenced from comment 32 is what I have now
> > committed to GDB. So that is now official.
> 
> This gives us a new prospective. I would try immediately. Two questions that
> will save me some time:
> 
>      - Which GDB: version/backport, snapshot or take it from CVS?
>      - Is it still necessary have to apply the eCos back-trace patch
> (attachment 1540 [details])?
> 

I tried GDB-7.4.50.20120316 that I assume contains this patch. Two issues:

1. Building was breaking for the file /gdb/gnu-v3-abi.c with error "variable
might be used uninitialized". It builds after following workaround:

@@ -870,7 +870,7 @@
   for (i = 0; i <= max_voffset; ++i)
     {
       struct value *vfn;
-      CORE_ADDR addr;
+      CORE_ADDR addr = 0; //VAE
       volatile struct gdb_exception ex;

       printf_filtered ("[%d]: ", i);

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.

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.

Ilija

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