From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Kevin Buettner Cc: Daniel Jacobowitz , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] W.I.P. AltiVec ppc registers support. Date: Thu, 29 Nov 2001 15:33:00 -0000 Message-ID: <3C06C5DA.70609@cygnus.com> References: <15365.39495.801289.497931@krustylu.cygnus.com> <1011129183830.ZM18856@ocotillo.lan> <15366.44991.616576.411278@krustylu.cygnus.com> <1011129222000.ZM19585@ocotillo.lan> <20011129174621.B15429@nevyn.them.org> <1011129231229.ZM19791@ocotillo.lan> X-SW-Source: 2001-11/msg00583.html Message-ID: <20011129153300.y7DPc70K9diLKCAxVvGqMgVGxThqf581l99flyt0DHE@z> > > I haven't seen your patches, but I imagine you have a table of > constants or some such that represent offsets and sizes of members in > the regsets? (I.e, something similar to what I did for SVR4 shared > library offsets.) If that's the approach, then the only real problem I > have with it is accurately generating (and maintaining) the tables. > The SVR4 shared library tables are compact enough to easily generate > by hand. The regset data is quite a lot larger and I would think > you'd want to generate this data through more automatic means. (I.e, > via a program that you'd compile and and then run on the target.) Isn't the situtation with core files identical to shlibs? If the layout changed then an old GDB couldn't debug new core files and a new GDB couldn't debug old core files. To avoid this, people do stuff like put new register sets into new sections. enjoy, Andrew