[Qemu-devel] [6967] Temporary workaround for ppc on ppc

[Qemu-devel] [6967] Temporary workaround for ppc on ppc

[malc]

Revision: 6967
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6967
Author:   malc
Date:     2009-04-02 01:16:39 +0000 (Thu, 02 Apr 2009)
Log Message:
-----------
Temporary workaround for ppc on ppc

target-ppc/translate.c puts values of type opcode_t into .opcodes
section, using GCC extension to do so, and hoping that this will make
them appear contiguously and in the source order in the resulting
executable. This assumption is not safe and is known to be violated
with certain versions of GCC, certain flags passed to it and on
certain platforms (gcc 4.3.0, -O and PPC/PPC64 for instance)

The workaround consists of adding -fno-unit-at-a-time to the list of
GCC command line options while building PPC translate.o on a PPC.

Modified Paths:
--------------
    trunk/Makefile.target

Modified: trunk/Makefile.target
===================================================================
--- trunk/Makefile.target	2009-04-01 23:10:46 UTC (rev 6966)
+++ trunk/Makefile.target	2009-04-02 01:16:39 UTC (rev 6967)
@@ -84,6 +84,10 @@
 HELPER_CFLAGS+=-fomit-frame-pointer
 endif
 
+ifeq ($(subst ppc64,ppc,$(ARCH))$(TARGET_BASE_ARCH),ppcppc)
+translate.o: CFLAGS := $(CFLAGS) $(call cc-option, $(CFLAGS), -fno-unit-at-a-time,)
+endif
+
 ifeq ($(ARCH),sparc)
   CFLAGS+=-ffixed-g2 -ffixed-g3
   ifneq ($(CONFIG_SOLARIS),yes)

Re: [Qemu-devel] [6967] Temporary workaround for ppc on ppc

[Blue Swirl]

On 4/2/09, malc <av1474@comtv.ru> wrote:
> Revision: 6967
>           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6967
>  Author:   malc
>  Date:     2009-04-02 01:16:39 +0000 (Thu, 02 Apr 2009)
>  Log Message:
>  -----------
>  Temporary workaround for ppc on ppc
>
>  target-ppc/translate.c puts values of type opcode_t into .opcodes
>  section, using GCC extension to do so, and hoping that this will make
>  them appear contiguously and in the source order in the resulting
>  executable. This assumption is not safe and is known to be violated
>  with certain versions of GCC, certain flags passed to it and on
>  certain platforms (gcc 4.3.0, -O and PPC/PPC64 for instance)

I've always wondered if the section hack was a very clever one or too
clever one, this makes it clear.

The section uses could be removed by moving the opcode tables towards
the end of file and making the handler functions use normal C
declarations or aided with a macro. That separates the function and
its table entry a lot, but I guess we don't want to use the #include
trick this time?

Re: [Qemu-devel] [6967] Temporary workaround for ppc on ppc

[malc]

On Thu, 2 Apr 2009, Blue Swirl wrote:

> On 4/2/09, malc <av1474@comtv.ru> wrote:
> > Revision: 6967
> >           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6967
> >  Author:   malc
> >  Date:     2009-04-02 01:16:39 +0000 (Thu, 02 Apr 2009)
> >  Log Message:
> >  -----------
> >  Temporary workaround for ppc on ppc
> >
> >  target-ppc/translate.c puts values of type opcode_t into .opcodes
> >  section, using GCC extension to do so, and hoping that this will make
> >  them appear contiguously and in the source order in the resulting
> >  executable. This assumption is not safe and is known to be violated
> >  with certain versions of GCC, certain flags passed to it and on
> >  certain platforms (gcc 4.3.0, -O and PPC/PPC64 for instance)
> 
> I've always wondered if the section hack was a very clever one or too
> clever one, this makes it clear.
> 
> The section uses could be removed by moving the opcode tables towards

There are _no_ opcode tables that's why it fails. The code just does

opcode_t in_section(.opcodes) start;
<lots of opcode_t>;
opcode_t in_section(.opcodes) end;

And then scans from &start to &end.

The only way, that i know of, to make that work is to indeed put
things into a table (an array).

> the end of file and making the handler functions use normal C
> declarations or aided with a macro. That separates the function and
> its table entry a lot, but I guess we don't want to use the #include
> trick this time?

I think PPC's translate.c should be just split and massaged a lot.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [6967] Temporary workaround for ppc on ppc

[Blue Swirl]

On 4/2/09, malc <av1474@comtv.ru> wrote:
> On Thu, 2 Apr 2009, Blue Swirl wrote:
>
>  > On 4/2/09, malc <av1474@comtv.ru> wrote:
>  > > Revision: 6967
>  > >           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6967
>  > >  Author:   malc
>  > >  Date:     2009-04-02 01:16:39 +0000 (Thu, 02 Apr 2009)
>  > >  Log Message:
>  > >  -----------
>  > >  Temporary workaround for ppc on ppc
>  > >
>  > >  target-ppc/translate.c puts values of type opcode_t into .opcodes
>  > >  section, using GCC extension to do so, and hoping that this will make
>  > >  them appear contiguously and in the source order in the resulting
>  > >  executable. This assumption is not safe and is known to be violated
>  > >  with certain versions of GCC, certain flags passed to it and on
>  > >  certain platforms (gcc 4.3.0, -O and PPC/PPC64 for instance)
>  >
>  > I've always wondered if the section hack was a very clever one or too
>  > clever one, this makes it clear.
>  >
>  > The section uses could be removed by moving the opcode tables towards
>
>
> There are _no_ opcode tables that's why it fails. The code just does
>
>  opcode_t in_section(.opcodes) start;
>  <lots of opcode_t>;
>  opcode_t in_section(.opcodes) end;
>
>  And then scans from &start to &end.
>
>  The only way, that i know of, to make that work is to indeed put
>  things into a table (an array).

Yes, that's what I meant.

The alternative is to move the opcodes to a new file, which is
included two times by translate.c, first to get the opcode function
definitions and second time to construct the table. This is what I
meant with the #include trick below.

>  > the end of file and making the handler functions use normal C
>  > declarations or aided with a macro. That separates the function and
>  > its table entry a lot, but I guess we don't want to use the #include
>  > trick this time?
>
>
> I think PPC's translate.c should be just split and massaged a lot.

Fully agree.

Re: [Qemu-devel] [6967] Temporary workaround for ppc on ppc

[malc]

On Thu, 2 Apr 2009, Blue Swirl wrote:

> On 4/2/09, malc <av1474@comtv.ru> wrote:
> > On Thu, 2 Apr 2009, Blue Swirl wrote:
> >
> >  > On 4/2/09, malc <av1474@comtv.ru> wrote:
> >  > > Revision: 6967
> >  > >           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6967
> >  > >  Author:   malc
> >  > >  Date:     2009-04-02 01:16:39 +0000 (Thu, 02 Apr 2009)
> >  > >  Log Message:
> >  > >  -----------
> >  > >  Temporary workaround for ppc on ppc
> >  > >
> >  > >  target-ppc/translate.c puts values of type opcode_t into .opcodes
> >  > >  section, using GCC extension to do so, and hoping that this will make
> >  > >  them appear contiguously and in the source order in the resulting
> >  > >  executable. This assumption is not safe and is known to be violated
> >  > >  with certain versions of GCC, certain flags passed to it and on
> >  > >  certain platforms (gcc 4.3.0, -O and PPC/PPC64 for instance)
> >  >
> >  > I've always wondered if the section hack was a very clever one or too
> >  > clever one, this makes it clear.
> >  >
> >  > The section uses could be removed by moving the opcode tables towards
> >
> >
> > There are _no_ opcode tables that's why it fails. The code just does
> >
> >  opcode_t in_section(.opcodes) start;
> >  <lots of opcode_t>;
> >  opcode_t in_section(.opcodes) end;
> >
> >  And then scans from &start to &end.
> >
> >  The only way, that i know of, to make that work is to indeed put
> >  things into a table (an array).
> 
> Yes, that's what I meant.
> 
> The alternative is to move the opcodes to a new file, which is
> included two times by translate.c, first to get the opcode function
> definitions and second time to construct the table. This is what I
> meant with the #include trick below.

That should work yeah.
 
> >  > the end of file and making the handler functions use normal C
> >  > declarations or aided with a macro. That separates the function and
> >  > its table entry a lot, but I guess we don't want to use the #include
> >  > trick this time?
> >
> >
> > I think PPC's translate.c should be just split and massaged a lot.
> 
> Fully agree.
> 
> 

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [6967] Temporary workaround for ppc on ppc

[Mark McLoughlin]

On Thu, 2009-04-02 at 01:16 +0000, malc wrote:
> Revision: 6967
>           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6967
> Author:   malc
> Date:     2009-04-02 01:16:39 +0000 (Thu, 02 Apr 2009)
> Log Message:
> -----------
> Temporary workaround for ppc on ppc
> 
> target-ppc/translate.c puts values of type opcode_t into .opcodes
> section, using GCC extension to do so, and hoping that this will make
> them appear contiguously and in the source order in the resulting
> executable. This assumption is not safe and is known to be violated
> with certain versions of GCC, certain flags passed to it and on
> certain platforms (gcc 4.3.0, -O and PPC/PPC64 for instance)
> 
> The workaround consists of adding -fno-unit-at-a-time to the list of
> GCC command line options while building PPC translate.o on a PPC.
> 
> Modified Paths:
> --------------
>     trunk/Makefile.target
> 
> Modified: trunk/Makefile.target
> ===================================================================
> --- trunk/Makefile.target	2009-04-01 23:10:46 UTC (rev 6966)
> +++ trunk/Makefile.target	2009-04-02 01:16:39 UTC (rev 6967)
> @@ -84,6 +84,10 @@
>  HELPER_CFLAGS+=-fomit-frame-pointer
>  endif
>  
> +ifeq ($(subst ppc64,ppc,$(ARCH))$(TARGET_BASE_ARCH),ppcppc)
> +translate.o: CFLAGS := $(CFLAGS) $(call cc-option, $(CFLAGS), -fno-unit-at-a-time,)
> +endif
> +
>  ifeq ($(ARCH),sparc)
>    CFLAGS+=-ffixed-g2 -ffixed-g3
>    ifneq ($(CONFIG_SOLARIS),yes)
> 

Could we get this applied to the stable branch? It goes some way to
fixing qemu-system-ppc on a ppc host in Fedora 11:

  https://bugzilla.redhat.com/504273

Cheers,
Mark.

Re: [Qemu-devel] [6967] Temporary workaround for ppc on ppc

[malc]

On Mon, 8 Jun 2009, Mark McLoughlin wrote:

> On Thu, 2009-04-02 at 01:16 +0000, malc wrote:
> > Revision: 6967
> >           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6967
> > Author:   malc
> > Date:     2009-04-02 01:16:39 +0000 (Thu, 02 Apr 2009)
> > Log Message:
> > -----------
> > Temporary workaround for ppc on ppc
> > 
> > target-ppc/translate.c puts values of type opcode_t into .opcodes
> > section, using GCC extension to do so, and hoping that this will make
> > them appear contiguously and in the source order in the resulting
> > executable. This assumption is not safe and is known to be violated
> > with certain versions of GCC, certain flags passed to it and on
> > certain platforms (gcc 4.3.0, -O and PPC/PPC64 for instance)
> > 
> > The workaround consists of adding -fno-unit-at-a-time to the list of
> > GCC command line options while building PPC translate.o on a PPC.
> > 
> > Modified Paths:
> > --------------
> >     trunk/Makefile.target
> > 
> > Modified: trunk/Makefile.target
> > ===================================================================
> > --- trunk/Makefile.target	2009-04-01 23:10:46 UTC (rev 6966)
> > +++ trunk/Makefile.target	2009-04-02 01:16:39 UTC (rev 6967)
> > @@ -84,6 +84,10 @@
> >  HELPER_CFLAGS+=-fomit-frame-pointer
> >  endif
> >  
> > +ifeq ($(subst ppc64,ppc,$(ARCH))$(TARGET_BASE_ARCH),ppcppc)
> > +translate.o: CFLAGS := $(CFLAGS) $(call cc-option, $(CFLAGS), -fno-unit-at-a-time,)
> > +endif
> > +
> >  ifeq ($(ARCH),sparc)
> >    CFLAGS+=-ffixed-g2 -ffixed-g3
> >    ifneq ($(CONFIG_SOLARIS),yes)
> > 
> 
> Could we get this applied to the stable branch? It goes some way to
> fixing qemu-system-ppc on a ppc host in Fedora 11:
> 
>   https://bugzilla.redhat.com/504273

I was contemplating replacing it with less far reaching
-fno-toplevel-reorder, can you test if it works with whatever F11 is
shipping?

-- 
mailto:av1474@comtv.ru