From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9269 invoked by alias); 29 Nov 2001 23:33:48 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9245 invoked from network); 29 Nov 2001 23:33:47 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 23:33:47 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 41F603DE8; Thu, 29 Nov 2001 18:33:46 -0500 (EST) Message-ID: <3C06C5DA.70609@cygnus.com> Date: Tue, 20 Nov 2001 09:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Buettner Cc: Daniel Jacobowitz , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] W.I.P. AltiVec ppc registers support. 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00368.txt.bz2 > > 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 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