Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>, Kevin Buettner <kevinb@redhat.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] W.I.P. AltiVec ppc registers support.
Date: Tue, 20 Nov 2001 10:09:00 -0000	[thread overview]
Message-ID: <1011129234527.ZM19890@ocotillo.lan> (raw)
In-Reply-To: Daniel Jacobowitz <drow@mvista.com> "Re: [RFA] W.I.P. AltiVec ppc registers support." (Nov 29,  6:37pm)

On Nov 29,  6:37pm, Daniel Jacobowitz wrote:

> On Thu, Nov 29, 2001 at 04:12:29PM -0700, Kevin Buettner wrote:
> > > My still-unsubmitted cross-core patches for PowerPC remove
> > > core-regset.o also, and very unpleasantly turn ppc-linux-nat.c into a
> > > target-dependant rather than native-dependant file, so that we can grub
> > > through the gregsets by hand.  If you've got a better idea I'd love to
> > > hear it :) It will be made somewhat easier by the destruction of
> > > regmap[].
> > 
> > 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.)
> 
> Nothing that abstracted.  I copy the necessary type definitions and
> constants from target headers; they are "relatively" guaranteed never
> to change.  It's a mess.

How does the "cross" part of it work then?  Won't the sizes of the
fundamental types, struct alignment, etc. change depending upon
which host you compile it on?


WARNING: multiple messages have this Message-ID
From: Kevin Buettner <kevinb@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>, Kevin Buettner <kevinb@redhat.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] W.I.P. AltiVec ppc registers support.
Date: Thu, 29 Nov 2001 15:47:00 -0000	[thread overview]
Message-ID: <1011129234527.ZM19890@ocotillo.lan> (raw)
Message-ID: <20011129154700.9766SZHqa6t59ojFudwBZbvsVFbH05d8uDLR8sdh9iE@z> (raw)
In-Reply-To: <20011129183732.A17705@nevyn.them.org>

On Nov 29,  6:37pm, Daniel Jacobowitz wrote:

> On Thu, Nov 29, 2001 at 04:12:29PM -0700, Kevin Buettner wrote:
> > > My still-unsubmitted cross-core patches for PowerPC remove
> > > core-regset.o also, and very unpleasantly turn ppc-linux-nat.c into a
> > > target-dependant rather than native-dependant file, so that we can grub
> > > through the gregsets by hand.  If you've got a better idea I'd love to
> > > hear it :) It will be made somewhat easier by the destruction of
> > > regmap[].
> > 
> > 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.)
> 
> Nothing that abstracted.  I copy the necessary type definitions and
> constants from target headers; they are "relatively" guaranteed never
> to change.  It's a mess.

How does the "cross" part of it work then?  Won't the sizes of the
fundamental types, struct alignment, etc. change depending upon
which host you compile it on?


  parent reply	other threads:[~2001-11-29 23:47 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-28 18:09 Elena Zannoni
2001-11-18 13:27 ` Elena Zannoni
2001-11-18 14:11 ` Daniel Jacobowitz
2001-11-19 12:59   ` Andrew Cagney
2001-11-29  9:04     ` Andrew Cagney
2001-11-29 13:10     ` Daniel Jacobowitz
2001-11-19 16:00       ` Daniel Jacobowitz
2001-11-29 13:34       ` Kevin Buettner
2001-11-19 16:42         ` Kevin Buettner
2001-11-29 14:11         ` Kevin Buettner
2001-11-19 22:22           ` Kevin Buettner
2001-11-29 14:27           ` Elena Zannoni
2001-11-19 23:55             ` Elena Zannoni
2001-11-28 22:27   ` Daniel Jacobowitz
2001-12-02 10:28   ` Elena Zannoni
2001-12-02 12:19     ` Andrew Cagney
2001-12-02 14:59     ` Daniel Jacobowitz
2001-12-02 22:25       ` Andrew Cagney
2001-11-28 18:33 ` Daniel Jacobowitz
2001-11-18 13:40   ` Daniel Jacobowitz
2001-11-29 10:40 ` Kevin Buettner
2001-11-19 15:15   ` Kevin Buettner
2001-11-19 18:51   ` Elena Zannoni
2001-11-29 13:53     ` Elena Zannoni
2001-11-29 14:21     ` Kevin Buettner
2001-11-19 22:53       ` Kevin Buettner
2001-11-29 14:42       ` Elena Zannoni
2001-11-20  8:37         ` Elena Zannoni
2001-11-29 15:03         ` Andrew Cagney
2001-11-20  8:54           ` Andrew Cagney
2001-11-29 16:27           ` Kevin Buettner
2001-11-20 16:00             ` Kevin Buettner
2001-11-20 16:14             ` Andrew Cagney
2001-11-21  3:33               ` Daniel Jacobowitz
2001-11-29 17:41                 ` Daniel Jacobowitz
2001-11-29 16:43               ` Andrew Cagney
2001-11-29 16:36             ` Elena Zannoni
2001-11-20 16:10               ` Elena Zannoni
2001-11-29 17:40               ` Daniel Jacobowitz
2001-11-20 18:00                 ` Daniel Jacobowitz
2001-11-29 14:47       ` Daniel Jacobowitz
2001-11-20  8:37         ` Daniel Jacobowitz
2001-11-20  9:07         ` Kevin Buettner
2001-11-20  9:08           ` Andrew Cagney
2001-11-29 15:33             ` Andrew Cagney
2001-11-29 15:15           ` Kevin Buettner
2001-11-29 15:38           ` Daniel Jacobowitz
2001-11-20  9:13             ` Daniel Jacobowitz
2001-11-20 10:09             ` Kevin Buettner [this message]
2001-11-29 15:47               ` Kevin Buettner
2001-11-29 15:58               ` Andrew Cagney
2001-11-20 10:59                 ` Andrew Cagney
2001-11-29 15:59               ` Daniel Jacobowitz
2001-11-20 11:07                 ` Daniel Jacobowitz
2001-11-29 16:17                 ` Andrew Cagney
2001-11-20 11:17                   ` Andrew Cagney
2001-11-20 17:52                   ` Daniel Jacobowitz
2001-11-29 17:39                     ` Daniel Jacobowitz
2001-11-29 18:20                     ` Andrew Cagney
2001-11-21  4:10                       ` Andrew Cagney
2001-11-29 22:36                       ` Daniel Jacobowitz
2001-11-21  5:56                         ` Daniel Jacobowitz
2001-12-20 10:02         ` Elena Zannoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1011129234527.ZM19890@ocotillo.lan \
    --to=kevinb@redhat.com \
    --cc=drow@mvista.com \
    --cc=ezannoni@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox