From: Pedro Alves <pedro@codesourcery.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: gdb-patches@sourceware.org, toolchain-devel@blackfin.uclinux.org
Subject: Re: [PATCH v3] gdb: bfin: new port
Date: Wed, 15 Dec 2010 18:01:00 -0000 [thread overview]
Message-ID: <201012151800.52772.pedro@codesourcery.com> (raw)
In-Reply-To: <201012151207.12141.vapier@gentoo.org>
On Wednesday 15 December 2010 17:07:11, Mike Frysinger wrote:
> > It all looks like you should really make the PC and the CC registers
> > pseudo registers handled by gdb, and not pass them on the remote
> > protocol wire, getting rid of all the possibility of confusing
> > out-of-sync iret/pc, astat/cc.
>
> the trouble with PC is that it isnt always RETI. with a Linux userspace app,
> the PC is managed indirectly via RETI (by nature of the sequencer). but this
> all depends on the level the remote stub is operating at. it could possibly
> be indirectly handled by RETX or RETN or RETE as well.
> so i think the PC
> logic needs to be left up to the remote stub to properly manage. i dont think
> we need to worry about people attempting to screw with any of the supervisor
> level registers (RET[IXNE]) because they arent allowed to in usermode and they
> make no sense unless you're in any of those contexts
> (interrupt/exception/nmi/emulation).
I see. Does the correct pc register depend on context (in exception, in
interrupt, in normal code, in whatnot), or is it always fixed per stub? If
the latter, it sounds like something that should be handled by a xml target
description that somehow tells gdb which register is the pc (sounds more
complicated than it is, I think). If the former, is there any way to tell
which is the correct register by reading some other register, perhaps?
Otherwise, yeah, best keep it a separate register, which is a bit of a
shame...
--
Pedro Alves
next prev parent reply other threads:[~2010-12-15 18:01 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-09 9:29 [PATCH v2] " Mike Frysinger
2010-12-09 9:31 ` [PATCH v2] gdbserver: " Mike Frysinger
2010-12-13 18:44 ` Pedro Alves
2010-12-13 19:24 ` Mike Frysinger
2010-12-14 9:37 ` Andrew Stubbs
2010-12-14 15:10 ` Mike Frysinger
2010-12-14 16:31 ` Pedro Alves
2010-12-14 16:58 ` Mike Frysinger
2010-12-14 17:16 ` Andrew Stubbs
2010-12-14 17:26 ` Mike Frysinger
2010-12-15 11:54 ` Andrew Stubbs
2010-12-15 12:55 ` [toolchain-devel] " Mike Frysinger
2010-12-15 13:17 ` Andrew Stubbs
2010-12-14 17:40 ` Pedro Alves
2010-12-14 17:48 ` Mike Frysinger
2010-12-14 18:06 ` Pedro Alves
2010-12-14 18:21 ` Mike Frysinger
2010-12-15 16:54 ` Mike Frysinger
2010-12-14 6:03 ` [PATCH v2] gdb: " Joel Brobecker
2010-12-14 16:14 ` Mike Frysinger
2010-12-14 20:43 ` [PATCH v3] " Mike Frysinger
2010-12-14 21:31 ` Pedro Alves
2010-12-14 22:01 ` Mike Frysinger
2010-12-15 13:02 ` Mike Frysinger
2010-12-15 16:53 ` Pedro Alves
2010-12-15 17:08 ` Mike Frysinger
2010-12-15 18:01 ` Pedro Alves [this message]
2010-12-15 18:38 ` Mike Frysinger
2010-12-15 18:42 ` Pedro Alves
2010-12-15 18:16 ` Mike Frysinger
2010-12-15 18:25 ` Pedro Alves
2010-12-14 21:48 ` [PATCH v3] gdbserver: " Mike Frysinger
2010-12-14 23:03 ` Ralf Corsepius
2010-12-15 0:15 ` Mike Frysinger
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=201012151800.52772.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=toolchain-devel@blackfin.uclinux.org \
--cc=vapier@gentoo.org \
/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