does this mean this problem is currently not fixable (and maybe "never" - in a considerable amount of time will ?)
On Fri, 22 Apr 2005 17:33:25 +0100 Paul Brook <[EMAIL PROTECTED]> wrote: > On Friday 22 April 2005 17:12, Jonas Maebe wrote: > > On 22 apr 2005, at 17:41, [EMAIL PROTECTED] wrote: > > > Hello Jonas, here is the output of the command you gave me for this > > > function, does this help ? > > > > It helps in the sense that it confirms my suspicion, although I don't > > know why it creates such convoluted code. Maybe in order to have as > > small code as possible with at the same time as many aligned jump > > targets as possible. It's definitely not trivial to parse this, and > > even less trivial to rewrite it so it is usable for qemu's purposes (in > > this particular case, the retq could be replaced by a jmp, but you > > can't count on there being 4 padding bytes after each ret). > > > > You (or someone else) will have to find a way to force gcc 4.0 to put > > one ret (or jump) at the very end of the code it generates. If that's > > not possible, it will be quite hard to support gcc 4.0 in qemu... > > It's not possible to force gcc4 to put the "ret" at the end of the code. > > Paul > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
