From: Daniel Jacobowitz <drow@false.org>
To: Ignaz Forster <ignaz.forster@gmx.de>
Cc: gdb@sourceware.org
Subject: Re: Support for PPC405 / PPC440 registers
Date: Mon, 26 Mar 2007 20:38:00 -0000 [thread overview]
Message-ID: <20070326203839.GA8617@caradoc.them.org> (raw)
In-Reply-To: <46082CD9.6080002@gmx.de>
On Mon, Mar 26, 2007 at 10:28:09PM +0200, Ignaz Forster wrote:
> I recently tried to debug an embedded IBM PowerPC 405 and 440 over JTAG.
> The necessary GDB stub was written by myself (unfortunately using
> confidential information, so I won't be able to publish it).
>
> When trying to display the contents of the processor's registers I
> noticed only the PPC403 register layout was included in the standard GDB
> distribution. As the registers of the different processors in the
> 4xx-series differ, I tried to modify GDB and BFD to handle the registers
> of the additional processors. The following files were changed:
Since you have your own GDB stub, I would suggest that you approach
this from a different direction. The old "set architecture" appproach
has a problem: it requires manual intervention, because the
architecture of the file doesn't sufficiently tell us what registers
the target debug agent can supply.
GDB in CVS (after 6.6) has a new approach for customized targets; see
the "Target Descriptions" appendix in the current manual, here:
http://sourceware.org/gdb/current/onlinedocs/gdb_toc.html
There's no PowerPC support for this feature yet. But there's a
chapter in the GDB Internals manual which describes how to add support
to a new architecture:
http://sourceware.org/gdb/current/onlinedocs/gdbint_toc.html
Basically, you write a little XML file. Your debug agent tells GDB
when it connects that it supports the XML description language, and
GDB fetches the description automatically. As long as you mention all
the standard core registers, you can add any other registers you
please. The new registers go right into the g/G packets, like other
registers.
> Question 1: What did I destroy by doing this?
Probably nothing.
> Question 2: Would a patch to add support for these processors be useful?
I'd rather you try the new way, if you have time.
> What else should be done before even thinking about doing so?
If you'd like to contribute to GDB, you'll need a copyright
assignment. If you're interested and do not already have one, please
let me know and I'll send you the form.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2007-03-26 20:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-26 20:26 Ignaz Forster
2007-03-26 20:38 ` Daniel Jacobowitz [this message]
2007-03-27 20:33 ` Ignaz Forster
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=20070326203839.GA8617@caradoc.them.org \
--to=drow@false.org \
--cc=gdb@sourceware.org \
--cc=ignaz.forster@gmx.de \
/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