All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-10 21:49 Thomas Renninger
  0 siblings, 0 replies; 12+ messages in thread
From: Thomas Renninger @ 2012-10-10 21:49 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On Wednesday 10 October 2012 17:42:58 Richard W.M. Jones wrote:
> 
> Here is a laundry-list of patches that fix various compiler warnings
> in the ACPICA code.
> 
> 'iasl-pointer-casts.patch' fixes a segfault on ppc64:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=856856
> 
> There is also an endianness assumption in the code on ppc64 which I'm
> still tracking down.

While code correctness across architectures is a good thing, especially
for acpica, but I am really curious about: Why should someone compile
acpica for ppc/ppc64?

Thanks,

   Thomas

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-11 16:36 Moore, Robert
  0 siblings, 0 replies; 12+ messages in thread
From: Moore, Robert @ 2012-10-11 16:36 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Well, this makes things easier.

Let me know if you find additional issues.
Bob


> -----Original Message-----
> From: Richard W.M. Jones [mailto:rjones(a)redhat.com]
> Sent: Thursday, October 11, 2012 9:06 AM
> To: Moore, Robert
> Cc: Thomas Renninger; devel(a)acpica.org; Matthew Garrett
> Subject: Re: [Devel] [PATCHES] Various fixes for Fedora
> 
> On Thu, Oct 11, 2012 at 03:29:52PM +0000, Moore, Robert wrote:
> > The current version is 20120913.
> 
> So we are ...  I've put the latest version into Fedora and it doesn't need
> these patches.
> 
> Sorry for the noise.
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones virt-df lists disk usage of guests
> without needing to install any software inside the virtual machine.
> Supports Linux and Windows.
> http://et.redhat.com/~rjones/virt-df/

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-11 16:06 Richard W.M. Jones
  0 siblings, 0 replies; 12+ messages in thread
From: Richard W.M. Jones @ 2012-10-11 16:06 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Thu, Oct 11, 2012 at 03:29:52PM +0000, Moore, Robert wrote:
> The current version is 20120913.

So we are ...  I've put the latest version into Fedora and it
doesn't need these patches.

Sorry for the noise.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-11 15:29 Moore, Robert
  0 siblings, 0 replies; 12+ messages in thread
From: Moore, Robert @ 2012-10-11 15:29 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

So, this is for the iASL compiler only. Of course, iASL pulls in huge chunks of the core ACPICA code, so this is kind of moot.


I just noticed that you are using a version of the source that is over two years old:

> diff -ur acpica-unix-20100528.old/compiler/Makefile acpica-unix-20100528/compiler/Makefile
> --- acpica-unix-20100528.old/compiler/Makefile	2012-10-10 14:26:24.910788185 +0200
> +++ acpica-unix-20100528/compiler/Makefile	2012-10-10 14:33:10.570794691 +0200


The current version is 20120913.

Please migrate to the latest version.
Thanks,
Bob



> -----Original Message-----
> From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
> Of Richard W.M. Jones
> Sent: Thursday, October 11, 2012 12:24 AM
> To: Thomas Renninger
> Cc: devel(a)acpica.org; Matthew Garrett
> Subject: Re: [Devel] [PATCHES] Various fixes for Fedora
> 
> 
> On Wed, Oct 10, 2012 at 11:49:20PM +0200, Thomas Renninger wrote:
> > On Wednesday 10 October 2012 17:42:58 Richard W.M. Jones wrote:
> > >
> > > Here is a laundry-list of patches that fix various compiler warnings
> > > in the ACPICA code.
> > >
> > > 'iasl-pointer-casts.patch' fixes a segfault on ppc64:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=856856
> > >
> > > There is also an endianness assumption in the code on ppc64 which
> > > I'm still tracking down.
> >
> > While code correctness across architectures is a good thing,
> > especially for acpica, but I am really curious about: Why should
> > someone compile acpica for ppc/ppc64?
> 
> For the (very esoteric and rarely used) case where someone wants to
> compile qemu{,-system-x86_64} from source on ppc.
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones virt-top is 'top' for virtual machines.
> Tiny program with many powerful monitoring features, net stats, disk
> stats, logging, etc.
> http://et.redhat.com/~rjones/virt-top
> _______________________________________________
> Devel mailing list
> Devel(a)acpica.org
> http://lists.acpica.org/listinfo/devel

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-11  7:24 Richard W.M. Jones
  0 siblings, 0 replies; 12+ messages in thread
From: Richard W.M. Jones @ 2012-10-11  7:24 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]


On Wed, Oct 10, 2012 at 11:49:20PM +0200, Thomas Renninger wrote:
> On Wednesday 10 October 2012 17:42:58 Richard W.M. Jones wrote:
> > 
> > Here is a laundry-list of patches that fix various compiler warnings
> > in the ACPICA code.
> > 
> > 'iasl-pointer-casts.patch' fixes a segfault on ppc64:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=856856
> > 
> > There is also an endianness assumption in the code on ppc64 which I'm
> > still tracking down.
> 
> While code correctness across architectures is a good thing, especially
> for acpica, but I am really curious about: Why should someone compile
> acpica for ppc/ppc64?

For the (very esoteric and rarely used) case where someone wants
to compile qemu{,-system-x86_64} from source on ppc.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-10 20:41 Moore, Robert
  0 siblings, 0 replies; 12+ messages in thread
From: Moore, Robert @ 2012-10-10 20:41 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]



> -----Original Message-----
> From: Richard W.M. Jones [mailto:rjones(a)redhat.com]
> Sent: Wednesday, October 10, 2012 1:36 PM
> To: Moore, Robert
> Cc: trenn(a)suse.de; Matthew Garrett; devel(a)acpica.org
> Subject: Re: [Devel] [PATCHES] Various fixes for Fedora
> 
> On Wed, Oct 10, 2012 at 08:28:36PM +0000, Moore, Robert wrote:
> > ACPI_CAST_PTR casts via an integral type (ACPI_UINTPTR_T) which can be
> > a different size from the ACPI_PHYSICAL_ADDRESS.  gcc doesn't like
> > this.  The number is really just an int, so just print it using "%d".
> >
> > diff -ur acpica-unix-20100528.old/namespace/nsdump.c acpica-unix-
> 20100528/namespace/nsdump.c
> > --- acpica-unix-20100528.old/namespace/nsdump.c	2010-05-28
> 19:14:40.000000000 +0200
> > +++ acpica-unix-20100528/namespace/nsdump.c	2012-10-10
> 14:38:18.760798740 +0200
> > @@ -353,9 +353,9 @@
> >          {
> >          case ACPI_TYPE_PROCESSOR:
> >
> > -            AcpiOsPrintf ("ID %X Len %.4X Addr %p\n",
> > +            AcpiOsPrintf ("ID %X Len %.4X Addr %d\n",
> >                  ObjDesc->Processor.ProcId, ObjDesc->Processor.Length,
> > -                ACPI_CAST_PTR (void, ObjDesc->Processor.Address));
> > +		ObjDesc->Processor.Address);
> >              break;
> >
> >
> > The reason we end up doing things like this is because "int" is 32
> > bits under most models (LP64, LLP64, and ILP64.) The only model where
> > int becomes a 64-bit value is under ILP64. So really, we have found
> > that the only way to output something that can change from 32-bit to
> > 64-bit automatically (and portably) is to pretend it is a pointer.
> 
> How about using the standardized <inttypes.h>, something like:
> 
>   #include <inttypes.h>
> 
>   #if ACPI_MACHINE_WIDTH == 64
>   #define PR_ADDRESS PRIi64
>   #else
>   #define PR_ADDRESS PRIi32
>   #endif
> 
>   //...
> 
>   AcpiOsPrintf ("ID %X Len %.4X Addr %" PR_ADDRESS "\n", ...)
> 

Unfortunately, I don't think that this would be portable enough for ACPICA. We would need to implement our own version(s).







> > What version of gcc are you using? We don't see this issue here with
> > everything up to gcc version 4.7.1
> 
> gcc 4.7.1, but note that the problem was seen on ppc64 (LP64).
> I was a bit surprised too by the warning, since it seemed to be casting
> through the same sized integer (64 bits).
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones virt-p2v converts physical machines to
> virtual machines.  Boot with a live CD or over the network (PXE) and turn
> machines into Xen guests.
> http://et.redhat.com/~rjones/virt-p2v

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-10 20:35 Richard W.M. Jones
  0 siblings, 0 replies; 12+ messages in thread
From: Richard W.M. Jones @ 2012-10-10 20:35 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

On Wed, Oct 10, 2012 at 08:28:36PM +0000, Moore, Robert wrote:
> ACPI_CAST_PTR casts via an integral type (ACPI_UINTPTR_T) which can be
> a different size from the ACPI_PHYSICAL_ADDRESS.  gcc doesn't like
> this.  The number is really just an int, so just print it using "%d".
> 
> diff -ur acpica-unix-20100528.old/namespace/nsdump.c acpica-unix-20100528/namespace/nsdump.c
> --- acpica-unix-20100528.old/namespace/nsdump.c	2010-05-28 19:14:40.000000000 +0200
> +++ acpica-unix-20100528/namespace/nsdump.c	2012-10-10 14:38:18.760798740 +0200
> @@ -353,9 +353,9 @@
>          {
>          case ACPI_TYPE_PROCESSOR:
>  
> -            AcpiOsPrintf ("ID %X Len %.4X Addr %p\n",
> +            AcpiOsPrintf ("ID %X Len %.4X Addr %d\n",
>                  ObjDesc->Processor.ProcId, ObjDesc->Processor.Length,
> -                ACPI_CAST_PTR (void, ObjDesc->Processor.Address));
> +		ObjDesc->Processor.Address);
>              break;
> 
>
> The reason we end up doing things like this is because "int" is 32
> bits under most models (LP64, LLP64, and ILP64.) The only model
> where int becomes a 64-bit value is under ILP64. So really, we have
> found that the only way to output something that can change from
> 32-bit to 64-bit automatically (and portably) is to pretend it is a
> pointer.

How about using the standardized <inttypes.h>, something like:

  #include <inttypes.h>

  #if ACPI_MACHINE_WIDTH == 64
  #define PR_ADDRESS PRIi64
  #else
  #define PR_ADDRESS PRIi32
  #endif

  //...

  AcpiOsPrintf ("ID %X Len %.4X Addr %" PR_ADDRESS "\n", ...)

> What version of gcc are you using? We don't see this issue here with
> everything up to gcc version 4.7.1

gcc 4.7.1, but note that the problem was seen on ppc64 (LP64).
I was a bit surprised too by the warning, since it seemed to
be casting through the same sized integer (64 bits).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-10 20:28 Moore, Robert
  0 siblings, 0 replies; 12+ messages in thread
From: Moore, Robert @ 2012-10-10 20:28 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

ACPI_CAST_PTR casts via an integral type (ACPI_UINTPTR_T) which can be
a different size from the ACPI_PHYSICAL_ADDRESS.  gcc doesn't like
this.  The number is really just an int, so just print it using "%d".

diff -ur acpica-unix-20100528.old/namespace/nsdump.c acpica-unix-20100528/namespace/nsdump.c
--- acpica-unix-20100528.old/namespace/nsdump.c	2010-05-28 19:14:40.000000000 +0200
+++ acpica-unix-20100528/namespace/nsdump.c	2012-10-10 14:38:18.760798740 +0200
@@ -353,9 +353,9 @@
         {
         case ACPI_TYPE_PROCESSOR:
 
-            AcpiOsPrintf ("ID %X Len %.4X Addr %p\n",
+            AcpiOsPrintf ("ID %X Len %.4X Addr %d\n",
                 ObjDesc->Processor.ProcId, ObjDesc->Processor.Length,
-                ACPI_CAST_PTR (void, ObjDesc->Processor.Address));
+		ObjDesc->Processor.Address);
             break;


The reason we end up doing things like this is because "int" is 32 bits under most models (LP64, LLP64, and ILP64.) The only model where int becomes a 64-bit value is under ILP64. So really, we have found that the only way to output something that can change from 32-bit to 64-bit automatically (and portably) is to pretend it is a pointer.

What version of gcc are you using? We don't see this issue here with everything up to gcc version 4.7.1

Bob


> -----Original Message-----
> From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
> Of Richard W.M. Jones
> Sent: Wednesday, October 10, 2012 8:43 AM
> To: trenn(a)suse.de; Matthew Garrett; devel(a)acpica.org
> Subject: [Devel] [PATCHES] Various fixes for Fedora
> 
> 
> Here is a laundry-list of patches that fix various compiler warnings in
> the ACPICA code.
> 
> 'iasl-pointer-casts.patch' fixes a segfault on ppc64:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=856856
> 
> There is also an endianness assumption in the code on ppc64 which I'm
> still tracking down.
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones Read my programming blog:
> http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN
> alternative to F#)
> http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-10 20:20 Richard W.M. Jones
  0 siblings, 0 replies; 12+ messages in thread
From: Richard W.M. Jones @ 2012-10-10 20:20 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Wed, Oct 10, 2012 at 08:16:36PM +0000, Moore, Robert wrote:
> >Add -fno-strict-aliasing flag since the code does a lot of unsafe type
> punning and it's too difficult to fix all that.
> 
> diff -ur acpica-unix-20100528.old/compiler/Makefile acpica-unix-20100528/compiler/Makefile
> --- acpica-unix-20100528.old/compiler/Makefile	2012-10-10 14:26:24.910788185 +0200
> +++ acpica-unix-20100528/compiler/Makefile	2012-10-10 14:33:10.570794691 +0200
> @@ -125,7 +125,7 @@
>  	../osunixxf.c
>  
>  NOMAN=	YES
> -CFLAGS+= -Wall -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER -I../include -I../compiler
> +CFLAGS+= -Wall -fno-strict-aliasing -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER -I../include -I../compiler
>  
>  #YACC=	yacc
>  YACC=	bison
> 
> 
> I think we've been using this to accomplish the same thing in the makefiles under acpica/generate/unix:
> 
> 
>     -Wstrict-aliasing=0 \

This disables the warning.  My patch (-fno-strict-aliasing) turns off
the optimization itself.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-10 20:16 Moore, Robert
  0 siblings, 0 replies; 12+ messages in thread
From: Moore, Robert @ 2012-10-10 20:16 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

>Add -fno-strict-aliasing flag since the code does a lot of unsafe type
punning and it's too difficult to fix all that.

diff -ur acpica-unix-20100528.old/compiler/Makefile acpica-unix-20100528/compiler/Makefile
--- acpica-unix-20100528.old/compiler/Makefile	2012-10-10 14:26:24.910788185 +0200
+++ acpica-unix-20100528/compiler/Makefile	2012-10-10 14:33:10.570794691 +0200
@@ -125,7 +125,7 @@
 	../osunixxf.c
 
 NOMAN=	YES
-CFLAGS+= -Wall -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER -I../include -I../compiler
+CFLAGS+= -Wall -fno-strict-aliasing -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER -I../include -I../compiler
 
 #YACC=	yacc
 YACC=	bison


I think we've been using this to accomplish the same thing in the makefiles under acpica/generate/unix:


    -Wstrict-aliasing=0 \





> -----Original Message-----
> From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
> Of Moore, Robert
> Sent: Wednesday, October 10, 2012 8:51 AM
> To: Richard W.M. Jones; trenn(a)suse.de; Matthew Garrett; devel(a)acpica.org
> Cc: Zheng, Lv; Guan, Chao
> Subject: Re: [Devel] [PATCHES] Various fixes for Fedora
> 
> Thanks, we will take a look at integrating these.
> Bob
> 
> 
> > -----Original Message-----
> > From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On
> > Behalf Of Richard W.M. Jones
> > Sent: Wednesday, October 10, 2012 8:43 AM
> > To: trenn(a)suse.de; Matthew Garrett; devel(a)acpica.org
> > Subject: [Devel] [PATCHES] Various fixes for Fedora
> >
> >
> > Here is a laundry-list of patches that fix various compiler warnings
> > in the ACPICA code.
> >
> > 'iasl-pointer-casts.patch' fixes a segfault on ppc64:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=856856
> >
> > There is also an endianness assumption in the code on ppc64 which I'm
> > still tracking down.
> >
> > Rich.
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat
> > http://people.redhat.com/~rjones Read my programming blog:
> > http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the
> > OPEN alternative to F#)
> > http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
> _______________________________________________
> Devel mailing list
> Devel(a)acpica.org
> http://lists.acpica.org/listinfo/devel

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-10 15:50 Moore, Robert
  0 siblings, 0 replies; 12+ messages in thread
From: Moore, Robert @ 2012-10-10 15:50 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

Thanks, we will take a look at integrating these.
Bob


> -----Original Message-----
> From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On Behalf
> Of Richard W.M. Jones
> Sent: Wednesday, October 10, 2012 8:43 AM
> To: trenn(a)suse.de; Matthew Garrett; devel(a)acpica.org
> Subject: [Devel] [PATCHES] Various fixes for Fedora
> 
> 
> Here is a laundry-list of patches that fix various compiler warnings in
> the ACPICA code.
> 
> 'iasl-pointer-casts.patch' fixes a segfault on ppc64:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=856856
> 
> There is also an endianness assumption in the code on ppc64 which I'm
> still tracking down.
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones Read my programming blog:
> http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN
> alternative to F#)
> http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

^ permalink raw reply	[flat|nested] 12+ messages in thread
* [Devel] [PATCHES] Various fixes for Fedora
@ 2012-10-10 15:42 Richard W.M. Jones
  0 siblings, 0 replies; 12+ messages in thread
From: Richard W.M. Jones @ 2012-10-10 15:42 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]


Here is a laundry-list of patches that fix various compiler warnings
in the ACPICA code.

'iasl-pointer-casts.patch' fixes a segfault on ppc64:

https://bugzilla.redhat.com/show_bug.cgi?id=856856

There is also an endianness assumption in the code on ppc64 which I'm
still tracking down.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[-- Attachment #2: iasl-const-correctness.patch --]
[-- Type: text/plain, Size: 1484 bytes --]

diff -ur acpica-unix-20100528.old/compiler/aslcompiler.h acpica-unix-20100528/compiler/aslcompiler.h
--- acpica-unix-20100528.old/compiler/aslcompiler.h	2010-05-28 19:14:22.000000000 +0200
+++ acpica-unix-20100528/compiler/aslcompiler.h	2012-10-10 14:32:31.960794039 +0200
@@ -298,7 +298,7 @@
 
 int
 AslCompilererror(
-    char                    *s);
+    const char              *s);
 
 void
 AslCommonError (
@@ -309,7 +309,7 @@
     UINT32                  LogicalByteOffset,
     UINT32                  Column,
     char                    *Filename,
-    char                    *ExtraMessage);
+    const char              *ExtraMessage);
 
 void
 AePrintException (
diff -ur acpica-unix-20100528.old/compiler/aslerror.c acpica-unix-20100528/compiler/aslerror.c
--- acpica-unix-20100528.old/compiler/aslerror.c	2010-05-28 19:14:22.000000000 +0200
+++ acpica-unix-20100528/compiler/aslerror.c	2012-10-10 14:32:07.160793635 +0200
@@ -470,7 +470,7 @@
     UINT32                  LogicalByteOffset,
     UINT32                  Column,
     char                    *Filename,
-    char                    *ExtraMessage)
+    const char              *ExtraMessage)
 {
     UINT32                  MessageSize;
     char                    *MessageBuffer = NULL;
@@ -656,7 +656,7 @@
 
 int
 AslCompilererror (
-    char                    *CompilerMessage)
+    const char              *CompilerMessage)
 {
 
     AslCommonError (ASL_ERROR, ASL_MSG_SYNTAX, Gbl_CurrentLineNumber,

[-- Attachment #3: iasl-no-strict-aliasing.patch --]
[-- Type: text/plain, Size: 664 bytes --]

Add -fno-strict-aliasing flag since the code does a lot of unsafe type
punning and it's too difficult to fix all that.

diff -ur acpica-unix-20100528.old/compiler/Makefile acpica-unix-20100528/compiler/Makefile
--- acpica-unix-20100528.old/compiler/Makefile	2012-10-10 14:26:24.910788185 +0200
+++ acpica-unix-20100528/compiler/Makefile	2012-10-10 14:33:10.570794691 +0200
@@ -125,7 +125,7 @@
 	../osunixxf.c
 
 NOMAN=	YES
-CFLAGS+= -Wall -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER -I../include -I../compiler
+CFLAGS+= -Wall -fno-strict-aliasing -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER -I../include -I../compiler
 
 #YACC=	yacc
 YACC=	bison

[-- Attachment #4: iasl-nsdump.patch --]
[-- Type: text/plain, Size: 839 bytes --]

ACPI_CAST_PTR casts via an integral type (ACPI_UINTPTR_T) which can be
a different size from the ACPI_PHYSICAL_ADDRESS.  gcc doesn't like
this.  The number is really just an int, so just print it using "%d".

diff -ur acpica-unix-20100528.old/namespace/nsdump.c acpica-unix-20100528/namespace/nsdump.c
--- acpica-unix-20100528.old/namespace/nsdump.c	2010-05-28 19:14:40.000000000 +0200
+++ acpica-unix-20100528/namespace/nsdump.c	2012-10-10 14:38:18.760798740 +0200
@@ -353,9 +353,9 @@
         {
         case ACPI_TYPE_PROCESSOR:
 
-            AcpiOsPrintf ("ID %X Len %.4X Addr %p\n",
+            AcpiOsPrintf ("ID %X Len %.4X Addr %d\n",
                 ObjDesc->Processor.ProcId, ObjDesc->Processor.Length,
-                ACPI_CAST_PTR (void, ObjDesc->Processor.Address));
+		ObjDesc->Processor.Address);
             break;
 
 

[-- Attachment #5: iasl-pointer-casts.patch --]
[-- Type: text/plain, Size: 1988 bytes --]

On ppc64, these unsafe casts cause the pointers to be truncated,
causing a seg fault when compiling seabios
(https://bugzilla.redhat.com/show_bug.cgi?id=856856).

diff -ur acpica-unix-20100528.old/compiler/aslcompiler.y acpica-unix-20100528/compiler/aslcompiler.y
--- acpica-unix-20100528.old/compiler/aslcompiler.y	2010-05-28 19:14:22.000000000 +0200
+++ acpica-unix-20100528/compiler/aslcompiler.y	2012-10-10 14:29:48.530791373 +0200
@@ -2349,7 +2349,7 @@
     ;
 
 String
-    : PARSEOP_STRING_LITERAL        {$$ = TrCreateValuedLeafNode (PARSEOP_STRING_LITERAL, (ACPI_NATIVE_INT) AslCompilerlval.s);}
+    : PARSEOP_STRING_LITERAL        {$$ = TrCreateValuedLeafNode (PARSEOP_STRING_LITERAL, (UINT64) AslCompilerlval.s);}
     ;
 
 ConstTerm
@@ -2955,14 +2955,14 @@
 
 NameString
     : NameSeg                       {}
-    | PARSEOP_NAMESTRING            {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) AslCompilerlval.s);}
-    | PARSEOP_IO                    {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "IO");}
-    | PARSEOP_DMA                   {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "DMA");}
-    | PARSEOP_IRQ                   {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESTRING, (ACPI_NATIVE_INT) "IRQ");}
+    | PARSEOP_NAMESTRING            {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESTRING, (UINT64) AslCompilerlval.s);}
+    | PARSEOP_IO                    {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESTRING, (UINT64) "IO");}
+    | PARSEOP_DMA                   {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESTRING, (UINT64) "DMA");}
+    | PARSEOP_IRQ                   {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESTRING, (UINT64) "IRQ");}
     ;
 
 NameSeg
-    : PARSEOP_NAMESEG               {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESEG, (ACPI_NATIVE_INT) AslCompilerlval.s);}
+    : PARSEOP_NAMESEG               {$$ = TrCreateValuedLeafNode (PARSEOP_NAMESEG, (UINT64) AslCompilerlval.s);}
     ;
 
 

^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-10-11 16:36 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-10 21:49 [Devel] [PATCHES] Various fixes for Fedora Thomas Renninger
  -- strict thread matches above, loose matches on Subject: below --
2012-10-11 16:36 Moore, Robert
2012-10-11 16:06 Richard W.M. Jones
2012-10-11 15:29 Moore, Robert
2012-10-11  7:24 Richard W.M. Jones
2012-10-10 20:41 Moore, Robert
2012-10-10 20:35 Richard W.M. Jones
2012-10-10 20:28 Moore, Robert
2012-10-10 20:20 Richard W.M. Jones
2012-10-10 20:16 Moore, Robert
2012-10-10 15:50 Moore, Robert
2012-10-10 15:42 Richard W.M. Jones

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.