From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: Daniel Jacobowitz <drow@mvista.com>,
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 09:08:00 -0000 [thread overview]
Message-ID: <3C06C5DA.70609@cygnus.com> (raw)
In-Reply-To: <1011129231229.ZM19791@ocotillo.lan>
>
> 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
WARNING: multiple messages have this Message-ID
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: Daniel Jacobowitz <drow@mvista.com>,
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:33:00 -0000 [thread overview]
Message-ID: <3C06C5DA.70609@cygnus.com> (raw)
Message-ID: <20011129153300.y7DPc70K9diLKCAxVvGqMgVGxThqf581l99flyt0DHE@z> (raw)
In-Reply-To: <1011129231229.ZM19791@ocotillo.lan>
>
> 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
next prev parent reply other threads:[~2001-11-29 23:33 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 [this message]
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
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=3C06C5DA.70609@cygnus.com \
--to=ac131313@cygnus.com \
--cc=drow@mvista.com \
--cc=ezannoni@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kevinb@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