This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Fwd: Re: [patch] Add support for ARMv7M devices.


> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Friday, March 09, 2012 7:44 PM
> To: Jonathan Larmour
> Cc: gdb-patches@sourceware.org
> Subject: Re: Fwd: Re: [patch] Add support for ARMv7M devices.
> 
> On 03/09/2012 04:24 AM, Jonathan Larmour wrote:
> 
> > Over a year ago, after discussion and some helpful pointers from
> Daniel, I
> > submitted this patch:
> >
> > http://sourceware.org/ml/gdb-patches/2010-11/msg00142.html
> >
> > Unfortunately it fell by the wayside.
> >
> > This issue is coming to a head for the eCos project as we are
> updating our
> > ARM toolchain (we avoid the bleeding edge). However that means we
> really
> > need GDB to preserve backward compatibility, which it presently fails
> to do.
> >
> > We don't want to break backward compatibility with installed GDB
> stubs,
> 
> > and the XML solution is complicated for users, opaque, not really
> suitable
> 
> > for Eclipse (although there may be proprietary plugins around which
> try to
> > solve this, that isn't relevant for public GDB). Most importantly the
> > attached patch should flexibly work everywhere, and not break
> anyone's
> > compatibility. And furthermore, it allows us a clean migration path
> to the
> > changed 'g' packet length.
> >
> > So I'm attaching an updated version of the patch for current GDB
> trunk. If
> > it helps, I do have an FSF assignment and, from prehistory, commit
> > permissions.
> 
> 
> I support this.  I wrote essentially the same without being aware of
> your patch: <http://sourceware.org/ml/gdb-patches/2011-
> 04/msg00372.html>.
> 
> Wish I had seen yours before that.
> 
> If there are no other comments in a week or so, I say put this in.
> 
> On 03/09/2012 04:24 AM, Jonathan Larmour wrote:
> >  	}
> > +      else
> > +        is_m = 0;
> >
> 
> I think this is unnecessary though.  The variable is initialized to 0.
> 
> --
> Pedro Alves

Hi,

Sorry for bringing it back.

Can somebody please tell me how the "guess" mechanism works? How can the
buf_len in function process_g_packet become correct with "guess"?

Can we just make the arm-with-m.xml always include unnamed FPA registers? So
that it can cope with the case with or without FPA registers.

Thanks.
Terry




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]