From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.
Date: Sun, 1 May 2005 21:49:25 +0100 [thread overview]
Message-ID: <200505012149.26065.paul@codesourcery.com> (raw)
In-Reply-To: <5a8682dc45aca2e20b6d7926a147fa65@elis.ugent.be>
On Sunday 01 May 2005 21:29, Jonas Maebe wrote:
> On 01 May 2005, at 19:04, Paul Brook wrote:
> > This is not correct.
> > If the blr is not at the end of the function, things will break.
> > dyngen assumes the last instruction is the only return instruction in
> > the
> > function. This allows it to remove the blr insn and concatenate
> > multiple
> > functions together.
>
> Can't we on PPC just replace all blr's with plain branches to the
> instruction after end of the function? (since all instructions are 32
> bit long)
Yes, that should be work for ppc.
Obviously this doesn't help on x86/amd64 where a jump is longer than a ret.
you would have to copy the preceeding instruction[s] to make room for the
branch. You'd then need to redirect any jumps directly to the ret
instruction, and make them point at the copy.
Sparc may have similar problems because of jump delay slots (a jump is
effectively two instructions long.
Arm needs a bit of logic to follow jumps and figure out where the end of the
function is (ie. where the constant pool starts), but other that than the
same trick should work.
Overall it sounds like a tractable problem. It shouldn't matter if this
analysis takes a while because it's don'e while building qemu, not at
runtime.
Paul
prev parent reply other threads:[~2005-05-01 21:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-30 11:10 [Qemu-devel] [PATCH] Fix dyngen failure on PPC David Woodhouse
2005-05-01 17:04 ` Paul Brook
2005-05-01 20:15 ` Flavio Visentin
2005-05-01 20:35 ` Paul Brook
2005-05-01 20:29 ` Jonas Maebe
2005-05-01 20:49 ` Paul Brook [this message]
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=200505012149.26065.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).