Skip to contentSkip to conversation

iASL patches in Debian

PATCH In review [email protected] 5 participants 21 messages Jul 4, 2010 – Jul 15, 2010

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover iASL patches in Debian

Hi Robert,

Here is a series of patches that I've been carrying in the iasl Debian package for some time. They are all refreshed and reworked to apply cleanly on top of acpica-unix-20100528.
The series consists a couple of trivial patches to fix building on the FreeBSD and Hurd kernel flavours of Debian and some larger ones to enable compiling ASL on big endian architectures.
It would be great if you could apply the patches to your source tree and ship new release with this work included.
Let me know if you want me to run more tests or change something in the patches.

I tested building tests/misc/grammar.asl (plus a number or other DSDTs I have here) with the whole set applied and the results were identical on BE and LE machines as well as being identical to what a clean iasl produces on x86[1].
You can see build logs for all the architectures supported here:
https://buildd.debian.org/status/package.php?p=acpica-unix

Thanks

[1]: checked with (1) an hex dump of the AML file, (2) the C file generated with -tc and (3) by decompiling the AML to DSL on x86 and comparing the results.
As a side note pristine iasl on x86 sefaults when building test/misc/grammar.asl, with these patches applied it doesn't.

Signature · 1 line
mattia
#2 lore raw

PATCH 2/5 Small tweak to define uintptr_t and successfully build on debian/kfreebsd

---
 include/platform/acenv.h |    3 +++
 1 file changed, 3 insertions(+)
include/platform/acenv.h +3 -0
Index: b/include/platform/acenv.h
===================================================================
@@ -182,6 +182,9 @@
 
 
 /*! [Begin] no source code translation */
+#if defined(__GLIBC__)
+#include <stdint.h>
+#endif
 
 /******************************************************************************
  *
#4 lore raw

PATCH 4/5 Add architectures that do not support unaligned access and fix aligment issues

In reply to [email protected]
---
 compiler/asltree.c  |   15 ++++++++++-----
 executer/exoparg2.c |   12 +++++++++---
 include/actypes.h   |   26 +++++++++++++-------------
 3 files changed, 32 insertions(+), 21 deletions(-)
include/actypes.h +13 -13
Index: b/include/actypes.h
===================================================================
@@ -205,6 +205,19 @@
 
 /*! [End] no source code translation !*/
 
+/*
+ * In the case of the Itanium Processor Family (IPF), the hardware does not
+ * support misaligned memory transfers. Set the MISALIGNMENT_NOT_SUPPORTED flag
+ * to indicate that special precautions must be taken to avoid alignment faults.
+ * (IA64 or ia64 is currently used by existing compilers to indicate IPF.)
+ *
+ * Note: EM64T and other X86-64 processors support misaligned transfers,
+ * so there is no need to define this flag.
+ */
+#if defined (__IA64__) || defined (__ia64__) | defined(__alpha__) || defined(__sparc__) || defined(__hppa__) || defined(__arm__)
+#define ACPI_MISALIGNMENT_NOT_SUPPORTED
+#endif
+
 
 /*******************************************************************************
  *
@@ -231,19 +244,6 @@
 #define ACPI_SIZE_MAX                   ACPI_UINT64_MAX
 #define ACPI_USE_NATIVE_DIVIDE          /* Has native 64-bit integer support */
 
-/*
- * In the case of the Itanium Processor Family (IPF), the hardware does not
- * support misaligned memory transfers. Set the MISALIGNMENT_NOT_SUPPORTED flag
- * to indicate that special precautions must be taken to avoid alignment faults.
- * (IA64 or ia64 is currently used by existing compilers to indicate IPF.)
- *
- * Note: EM64T and other X86-64 processors support misaligned transfers,
- * so there is no need to define this flag.
- */
-#if defined (__IA64__) || defined (__ia64__)
-#define ACPI_MISALIGNMENT_NOT_SUPPORTED
-#endif
-
 
 /*******************************************************************************
  *
executer/exoparg2.c +9 -3
Index: b/executer/exoparg2.c
===================================================================
@@ -248,6 +248,8 @@
     ACPI_OPERAND_OBJECT     **Operand = &WalkState->Operands[0];
     ACPI_OPERAND_OBJECT     *ReturnDesc1 = NULL;
     ACPI_OPERAND_OBJECT     *ReturnDesc2 = NULL;
+    UINT64                  ReturnValue1 = 0;
+    UINT64                  ReturnValue2 = 0;
     ACPI_STATUS             Status;
 
 
@@ -281,8 +283,10 @@
 
         Status = AcpiUtDivide (Operand[0]->Integer.Value,
                                Operand[1]->Integer.Value,
-                               &ReturnDesc1->Integer.Value,
-                               &ReturnDesc2->Integer.Value);
+                               &ReturnValue1, &ReturnValue2);
+        ReturnDesc1->Integer.Value = ReturnValue1;
+        ReturnDesc2->Integer.Value = ReturnValue2;
+
         if (ACPI_FAILURE (Status))
         {
             goto Cleanup;
@@ -357,6 +361,7 @@
     ACPI_OPERAND_OBJECT     **Operand = &WalkState->Operands[0];
     ACPI_OPERAND_OBJECT     *ReturnDesc = NULL;
     UINT64                  Index;
+    UINT64                  ReturnValue = 0;
     ACPI_STATUS             Status = AE_OK;
     ACPI_SIZE               Length;
 
@@ -400,7 +405,8 @@
         Status = AcpiUtDivide (Operand[0]->Integer.Value,
                                Operand[1]->Integer.Value,
                                NULL,
-                               &ReturnDesc->Integer.Value);
+                               &ReturnValue);
+        ReturnDesc->Integer.Value = ReturnValue;
         break;
 
 
compiler/asltree.c +10 -5
Index: b/compiler/asltree.c
===================================================================
@@ -501,24 +501,27 @@
         "\nCreateValuedLeafNode  Ln/Col %u/%u NewNode %p  Op %s  Value %8.8X%8.8X  ",
         Op->Asl.LineNumber, Op->Asl.Column, Op, UtGetOpName(ParseOpcode),
         ACPI_FORMAT_UINT64 (Value));
-    Op->Asl.Value.Integer = Value;
 
     switch (ParseOpcode)
     {
     case PARSEOP_STRING_LITERAL:
-        DbgPrint (ASL_PARSE_OUTPUT, "STRING->%s", Value);
+        Op->Asl.Value.String = (ACPI_STRING) Value;
+        DbgPrint (ASL_PARSE_OUTPUT, "STRING->%s", (ACPI_STRING) Value);
         break;
 
     case PARSEOP_NAMESEG:
-        DbgPrint (ASL_PARSE_OUTPUT, "NAMESEG->%s", Value);
+        Op->Asl.Value.String = (ACPI_STRING) Value;
+        DbgPrint (ASL_PARSE_OUTPUT, "NAMESEG->%s", (ACPI_STRING) Value);
         break;
 
     case PARSEOP_NAMESTRING:
-        DbgPrint (ASL_PARSE_OUTPUT, "NAMESTRING->%s", Value);
+        Op->Asl.Value.String = (ACPI_STRING) Value;
+        DbgPrint (ASL_PARSE_OUTPUT, "NAMESTRING->%s", (ACPI_STRING) Value);
         break;
 
     case PARSEOP_EISAID:
-        DbgPrint (ASL_PARSE_OUTPUT, "EISAID->%s", Value);
+        Op->Asl.Value.String = (ACPI_STRING) Value;
+        DbgPrint (ASL_PARSE_OUTPUT, "EISAID->%s", (ACPI_STRING) Value);
         break;
 
     case PARSEOP_METHOD:
@@ -526,10 +529,12 @@
         break;
 
     case PARSEOP_INTEGER:
+        Op->Asl.Value.Integer = Value;
         DbgPrint (ASL_PARSE_OUTPUT, "INTEGER");
         break;
 
     default:
+        Op->Asl.Value.Integer = Value;
         break;
     }
 
#3 lore raw

PATCH 3/5 Support compiling DSDT tables on big endian architectures

In reply to [email protected]
---
 compiler/aslcodegen.c      |  107 +++++++++++++++++++++--------------
 compiler/aslopcodes.c      |    4 +
 compiler/aslrestype1.c     |   68 +++++++++++++++-------
 compiler/aslrestype1i.c    |   29 +++++----
 compiler/aslrestype2.c     |   25 +++++---
 compiler/aslrestype2d.c    |  134 +++++++++++++++++++++++++--------------------
 compiler/aslrestype2e.c    |  117 +++++++++++++++++++++++++++------------
 compiler/aslrestype2q.c    |  117 +++++++++++++++++++++++++--------------
 compiler/aslrestype2w.c    |  127 +++++++++++++++++++++++++-----------------
 include/acmacros.h         |   15 +++--
 include/platform/aclinux.h |    7 ++
 11 files changed, 470 insertions(+), 280 deletions(-)
include/platform/aclinux.h +6 -1
Index: b/include/platform/aclinux.h
===================================================================
@@ -156,13 +156,14 @@
 #include <stdlib.h>
 #include <ctype.h>
 #include <unistd.h>
+#include <endian.h>
 
 /* Host-dependent types and defines for user-space ACPICA */
 
 #define ACPI_FLUSH_CPU_CACHE()
 #define ACPI_THREAD_ID              pthread_t
 
-#if defined(__ia64__) || defined(__x86_64__)
+#if defined(__ia64__) || defined(__x86_64__) || defined(__alpha__)
 #define ACPI_MACHINE_WIDTH          64
 #define COMPILER_DEPENDENT_INT64    long
 #define COMPILER_DEPENDENT_UINT64   unsigned long
@@ -173,6 +174,10 @@
 #define ACPI_USE_NATIVE_DIVIDE
 #endif
 
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define ACPI_BIG_ENDIAN
+#endif
+
 #ifndef __cdecl
 #define __cdecl
 #endif
compiler/aslcodegen.c +63 -44

221 lines not on this page · raw message

compiler/aslopcodes.c +3 -1
Index: b/compiler/aslopcodes.c
===================================================================
@@ -449,6 +449,7 @@
     UINT32                  i;
     UINT8                   *AsciiString;
     UINT16                  *UnicodeString;
+    UINT16                  UChar;
     ACPI_PARSE_OBJECT       *BufferLengthOp;
 
 
@@ -475,7 +476,8 @@
 
     for (i = 0; i < Count; i++)
     {
-        UnicodeString[i] = (UINT16) AsciiString[i];
+        UChar = (UINT16) AsciiString[i];
+        ACPI_MOVE_16_TO_16(&UnicodeString[i], &UChar);
     }
 
     /*
compiler/aslrestype1.c +47 -21

180 lines not on this page · raw message

compiler/aslrestype1i.c +17 -12
Index: b/compiler/aslrestype1i.c
===================================================================
@@ -275,6 +275,7 @@
     ACPI_PARSE_OBJECT       *InitializerOp;
     ACPI_PARSE_OBJECT       *AddressOp = NULL;
     ASL_RESOURCE_NODE       *Rnode;
+    UINT16                  Address = 0;
     UINT32                  i;
 
 
@@ -293,8 +294,7 @@
         {
         case 0: /* Base Address */
 
-            Descriptor->FixedIo.Address =
-                (UINT16) InitializerOp->Asl.Value.Integer;
+            Address = InitializerOp->Asl.Value.Integer;
             RsCreateByteField (InitializerOp, ACPI_RESTAG_BASEADDRESS,
                 CurrentByteOffset + ASL_RESDESC_OFFSET (FixedIo.Address));
             AddressOp = InitializerOp;
@@ -324,11 +324,13 @@
 
     /* Error checks */
 
-    if (Descriptor->FixedIo.Address > 0x03FF)
+    if (Address > 0x03FF)
     {
         AslError (ASL_WARNING, ASL_MSG_ISA_ADDRESS, AddressOp, NULL);
     }
 
+    ACPI_MOVE_16_TO_16(&Descriptor->FixedIo.Address, &Address);
+
     return (Rnode);
 }
 
@@ -359,6 +361,8 @@
     ACPI_PARSE_OBJECT       *LengthOp = NULL;
     ACPI_PARSE_OBJECT       *AlignOp = NULL;
     ASL_RESOURCE_NODE       *Rnode;
+    UINT16                  Minimum = 0;
+    UINT16                  Maximum = 0;
     UINT32                  i;
 
 
@@ -384,8 +388,7 @@
 
         case 1:  /* Min Address */
 
-            Descriptor->Io.Minimum =
-                (UINT16) InitializerOp->Asl.Value.Integer;
+            Minimum = InitializerOp->Asl.Value.Integer;
             RsCreateByteField (InitializerOp, ACPI_RESTAG_MINADDR,
                 CurrentByteOffset + ASL_RESDESC_OFFSET (Io.Minimum));
             MinOp = InitializerOp;
@@ -393,8 +396,7 @@
 
         case 2: /* Max Address */
 
-            Descriptor->Io.Maximum =
-                (UINT16) InitializerOp->Asl.Value.Integer;
+            Maximum = InitializerOp->Asl.Value.Integer;
             RsCreateByteField (InitializerOp, ACPI_RESTAG_MAXADDR,
                 CurrentByteOffset + ASL_RESDESC_OFFSET (Io.Maximum));
             MaxOp = InitializerOp;
@@ -435,12 +437,15 @@
     /* Validate the Min/Max/Len/Align values */
 
     RsSmallAddressCheck (ACPI_RESOURCE_NAME_IO,
-        Descriptor->Io.Minimum,
-        Descriptor->Io.Maximum,
+        Minimum,
+        Maximum,
         Descriptor->Io.AddressLength,
         Descriptor->Io.Alignment,
         MinOp, MaxOp, LengthOp, AlignOp);
 
+    ACPI_MOVE_16_TO_16(&Descriptor->Io.Minimum, &Minimum);
+    ACPI_MOVE_16_TO_16(&Descriptor->Io.Maximum, &Maximum);
+
     return (Rnode);
 }
 
@@ -561,9 +566,9 @@
         InitializerOp = RsCompleteNodeAndGetNext (InitializerOp);
     }
 
-    /* Now we can set the channel mask */
+    /* Now we can set the interrupt mask */
 
-    Descriptor->Irq.IrqMask = IrqMask;
+    ACPI_MOVE_16_TO_16(&Descriptor->Irq.IrqMask, &IrqMask);
     return (Rnode);
 }
 
@@ -663,6 +668,6 @@
 
     /* Now we can set the interrupt mask */
 
-    Descriptor->Irq.IrqMask = IrqMask;
+    ACPI_MOVE_16_TO_16(&Descriptor->Irq.IrqMask, &IrqMask);
     return (Rnode);
 }
compiler/aslrestype2.c +16 -9
Index: b/compiler/aslrestype2.c
===================================================================
@@ -152,6 +152,7 @@
     AML_RESOURCE            *Descriptor;
     ACPI_PARSE_OBJECT       *InitializerOp;
     ASL_RESOURCE_NODE       *Rnode;
+    UINT16                  ResourceLength;
     UINT32                  i;
 
 
@@ -160,7 +161,9 @@
 
     Descriptor = Rnode->Buffer;
     Descriptor->GenericReg.DescriptorType = ACPI_RESOURCE_NAME_GENERIC_REGISTER;
-    Descriptor->GenericReg.ResourceLength = 12;
+    ResourceLength = 12;
+    ACPI_MOVE_16_TO_16(&Descriptor->GenericReg.ResourceLength,
+		    &ResourceLength);
 
     /* Process all child initialization nodes */
 
@@ -191,7 +194,8 @@
 
         case 3: /* Register Address */
 
-            Descriptor->GenericReg.Address = InitializerOp->Asl.Value.Integer;
+	    ACPI_MOVE_64_TO_64(&Descriptor->GenericReg.Address,
+			    &InitializerOp->Asl.Value.Integer);
             RsCreateByteField (InitializerOp, ACPI_RESTAG_ADDRESS,
                 CurrentByteOffset + ASL_RESDESC_OFFSET (GenericReg.Address));
             break;
@@ -249,6 +253,7 @@
     AML_RESOURCE            *Rover = NULL;
     ACPI_PARSE_OBJECT       *InitializerOp;
     ASL_RESOURCE_NODE       *Rnode;
+    UINT16                  ResourceLength = 0;
     UINT16                  StringLength = 0;
     UINT32                  OptionIndex = 0;
     UINT32                  i;
@@ -295,7 +300,7 @@
      * Initial descriptor length -- may be enlarged if there are
      * optional fields present
      */
-    Descriptor->ExtendedIrq.ResourceLength  = 2;  /* Flags and table length byte */
+    ResourceLength  = 2;  /* Flags and table length byte */
     Descriptor->ExtendedIrq.InterruptCount  = 0;
 
     Rover = ACPI_CAST_PTR (AML_RESOURCE,
@@ -403,10 +408,11 @@
 
             /* Save the integer and move pointer to the next one */
 
-            Rover->DwordItem = (UINT32) InitializerOp->Asl.Value.Integer;
+            ACPI_MOVE_64_TO_32(&Rover->DwordItem,
+                &InitializerOp->Asl.Value.Integer);
             Rover = ACPI_ADD_PTR (AML_RESOURCE, &(Rover->DwordItem), 4);
             Descriptor->ExtendedIrq.InterruptCount++;
-            Descriptor->ExtendedIrq.ResourceLength += 4;
+            ResourceLength += 4;
 
             /* Case 7: First interrupt number in list */
 
@@ -442,7 +448,7 @@
     {
         Rover->ByteItem = ResSourceIndex;
         Rover = ACPI_ADD_PTR (AML_RESOURCE, &(Rover->ByteItem), 1);
-        Descriptor->ExtendedIrq.ResourceLength += 1;
+        ResourceLength += 1;
     }
 
     /* Add optional ResSource string if present */
@@ -454,13 +460,14 @@
         Rover = ACPI_ADD_PTR (
                     AML_RESOURCE, &(Rover->ByteItem), StringLength);
 
-        Descriptor->ExtendedIrq.ResourceLength = (UINT16)
-            (Descriptor->ExtendedIrq.ResourceLength + StringLength);
+        ResourceLength = (UINT16) (ResourceLength + StringLength);
     }
 
     Rnode->BufferLength = (ASL_RESDESC_OFFSET (ExtendedIrq.Interrupts[0]) -
                            ASL_RESDESC_OFFSET (ExtendedIrq.DescriptorType))
                            + OptionIndex + StringLength;
+    ACPI_MOVE_16_TO_16(&Descriptor->ExtendedIrq.ResourceLength,
+		    &ResourceLength);
     return (Rnode);
 }
 
@@ -511,7 +518,7 @@
 
     Descriptor = Rnode->Buffer;
     Descriptor->VendorLarge.DescriptorType  = ACPI_RESOURCE_NAME_VENDOR_LARGE;
-    Descriptor->VendorLarge.ResourceLength = (UINT16) i;
+    ACPI_MOVE_32_TO_16(&Descriptor->VendorLarge.ResourceLength, &i);
 
     /* Point to end-of-descriptor for vendor data */
 
compiler/aslrestype2d.c +76 -58

328 lines not on this page · raw message

compiler/aslrestype2e.c +81 -36

291 lines not on this page · raw message

compiler/aslrestype2q.c +75 -42

310 lines not on this page · raw message

compiler/aslrestype2w.c +75 -52

316 lines not on this page · raw message

include/acmacros.h +11 -4
Index: b/include/acmacros.h
===================================================================
@@ -175,7 +175,8 @@
 
 /* 32-bit source, 16/32/64 destination */
 
-#define ACPI_MOVE_32_TO_16(d, s)        ACPI_MOVE_16_TO_16(d, s)    /* Truncate to 16 */
+#define ACPI_MOVE_32_TO_16(d, s)        {((  UINT8 *)(void *)(d))[0] = ((UINT8 *)(void *)(s))[3];\
+                                         ((  UINT8 *)(void *)(d))[1] = ((UINT8 *)(void *)(s))[2];}
 
 #define ACPI_MOVE_32_TO_32(d, s)        {((  UINT8 *)(void *)(d))[0] = ((UINT8 *)(void *)(s))[3];\
                                          ((  UINT8 *)(void *)(d))[1] = ((UINT8 *)(void *)(s))[2];\
@@ -190,9 +191,13 @@
 
 /* 64-bit source, 16/32/64 destination */
 
-#define ACPI_MOVE_64_TO_16(d, s)        ACPI_MOVE_16_TO_16(d, s)    /* Truncate to 16 */
+#define ACPI_MOVE_64_TO_16(d, s)        {((  UINT8 *)(void *)(d))[0] = ((UINT8 *)(void *)(s))[7];\
+                                         ((  UINT8 *)(void *)(d))[1] = ((UINT8 *)(void *)(s))[6];}
 
-#define ACPI_MOVE_64_TO_32(d, s)        ACPI_MOVE_32_TO_32(d, s)    /* Truncate to 32 */
+#define ACPI_MOVE_64_TO_32(d, s)        {((  UINT8 *)(void *)(d))[0] = ((UINT8 *)(void *)(s))[7];\
+                                         ((  UINT8 *)(void *)(d))[1] = ((UINT8 *)(void *)(s))[6];\
+                                         ((  UINT8 *)(void *)(d))[2] = ((UINT8 *)(void *)(s))[5];\
+                                         ((  UINT8 *)(void *)(d))[3] = ((UINT8 *)(void *)(s))[4];}
 
 #define ACPI_MOVE_64_TO_64(d, s)        {((  UINT8 *)(void *)(d))[0] = ((UINT8 *)(void *)(s))[7];\
                                          ((  UINT8 *)(void *)(d))[1] = ((UINT8 *)(void *)(s))[6];\
@@ -219,7 +224,9 @@
 
 /* 32-bit source, 16/32/64 destination */
 
-#define ACPI_MOVE_32_TO_16(d, s)        ACPI_MOVE_16_TO_16(d, s)    /* Truncate to 16 */
+#define ACPI_MOVE_32_TO_16(d, s)        {((  UINT8 *)(void *)(d))[0] = ((UINT8 *)(void *)(s))[0];\
+                                         ((  UINT8 *)(void *)(d))[1] = ((UINT8 *)(void *)(s))[1];}
+
 #define ACPI_MOVE_32_TO_32(d, s)        *(UINT32 *)(void *)(d) = *(UINT32 *)(void *)(s)
 #define ACPI_MOVE_32_TO_64(d, s)        *(UINT64 *)(void *)(d) = *(UINT32 *)(void *)(s)
 
#1 lore raw

PATCH 1/5 allow overriding only some of the CFLAGS

In reply to [email protected]
---
 compiler/Makefile         |    6 +++++-
 tools/acpiexec/Makefile   |    6 +++++-
 tools/acpisrc/Makefile    |    5 ++++-
 tools/acpixtract/Makefile |    5 ++++-
 4 files changed, 18 insertions(+), 4 deletions(-)
compiler/Makefile +5 -1
Index: b/compiler/Makefile
===================================================================
@@ -125,7 +125,8 @@
 	../osunixxf.c
 
 NOMAN=	YES
-CFLAGS+= -Wall -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER -I../include -I../compiler
+MK_CFLAGS = -DACPI_ASL_COMPILER -I../include -I../compiler
+CFLAGS= -Wall -Wstrict-prototypes -O2
 
 #YACC=	yacc
 YACC=	bison
@@ -141,6 +142,9 @@
 
 LDLIBS = -lpthread -lrt
 
+%.o: %.c
+	$(CC) $(MK_CFLAGS) $(CFLAGS) -c -o $@ $<
+
 aslmain : $(patsubst %.c,%.o, $(SRCS))
 	$(CC) $(LDFLAGS) $(patsubst %.c,%.o, $(SRCS)) \
 		$(LOADLIBES) $(LDLIBS) -o iasl
tools/acpiexec/Makefile +5 -1
Index: b/tools/acpiexec/Makefile
===================================================================
@@ -139,8 +139,12 @@
 	../../osunixxf.c
 
 
-CFLAGS+= -Wall -g -D_LINUX -DNDEBUG -D_CONSOLE -DACPI_EXEC_APP -D_MULTI_THREADED -Wstrict-prototypes -I../../include 
+MK_CFLAGS = -DNDEBUG -D_CONSOLE -DACPI_EXEC_APP -D_MULTI_THREADED \
+            -I../../include
+CFLAGS = -Wall -Wstrict-prototypes -O2 -g
 
+%.o: %.c
+	$(CC) $(MK_CFLAGS) $(CFLAGS) -c -o $@ $<
 
 acpiexec : $(patsubst %.c,%.o, $(SRCS))
 	$(CC) $(LDFLAGS) $(patsubst %.c,%.o, $(SRCS)) -lrt -lpthread -o $(PROG)
tools/acpisrc/Makefile +4 -1
Index: b/tools/acpisrc/Makefile
===================================================================
@@ -4,8 +4,11 @@
 SRCS=	ascase.c asconvrt.c asfile.c asmain.c asremove.c astable.c \
         asutils.c osunixdir.c ../../common/getopt.c
 
-CFLAGS+= -Wall -O2 -D_LINUX -DACPI_APPLICATION -Wstrict-prototypes -I../../include 
+MK_CFLAGS= -DACPI_APPLICATION -I../../include
+CFLAGS= -Wall -Wstrict-prototypes -O2
 
+%.o: %.c
+	$(CC) $(MK_CFLAGS) $(CFLAGS) -c -o $@ $<
 
 aslmain : $(patsubst %.c,%.o, $(SRCS))
 	$(CC) $(LDFLAGS) $(patsubst %.c,%.o, $(SRCS)) -o $(PROG)
tools/acpixtract/Makefile +4 -1
Index: b/tools/acpixtract/Makefile
===================================================================
@@ -3,8 +3,11 @@
 PROG=	acpixtract
 SRCS=	acpixtract.c
 
-CFLAGS+= -Wall -O2 -D_LINUX -DACPI_APPLICATION -Wstrict-prototypes -I../../include 
+MK_CFLAGS= -DACPI_APPLICATION -I../../include
+CFLAGS= -Wall -Wstrict-prototypes -O2
 
+%.o: %.c
+	$(CC) $(MK_CFLAGS) $(CFLAGS) -c -o $@ $<
 
 acpixtract : $(patsubst %.c,%.o, $(SRCS))
 	$(CC) $(LDFLAGS) $(patsubst %.c,%.o, $(SRCS)) -o $(PROG)
#5 lore raw

PATCH 5/5 Fix FTBFS on hurd-i386.

In reply to [email protected]
---
 include/platform/acenv.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/platform/acenv.h +1 -1
Index: b/include/platform/acenv.h
===================================================================
@@ -193,7 +193,7 @@
  *
  *****************************************************************************/
 
-#if defined(_LINUX) || defined(__linux__)
+#if defined(_LINUX) || defined(__linux__) || defined(__GNU__)
 #include "aclinux.h"
 
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
#6 lore raw
In reply to [email protected]
Quoted 13 lines · On Sun, 2010-07-04 at 12:43 +0800, [email protected] wrote:

Hi Robert,

Here is a series of patches that I've been carrying in the iasl Debian package for some time. They are all refreshed and reworked to apply cleanly on top of acpica-unix-20100528.
The series consists a couple of trivial patches to fix building on the FreeBSD and Hurd kernel flavours of Debian and some larger ones to enable compiling ASL on big endian architectures.
It would be great if you could apply the patches to your source tree and ship new release with this work included.
Let me know if you want me to run more tests or change something in the patches.

Quoted 6 lines

I tested building tests/misc/grammar.asl (plus a number or other DSDTs I have here) with the whole set applied and the results were identical on BE and LE machines as well as being identical to what a clean iasl produces on x86[1].
You can see build logs for all the architectures supported here:
https://buildd.debian.org/status/package.php?p=acpica-unix

Hi,

Thanks for the patches.

([email protected] is for linux-specific acpi dicussion. Better to post these patches to ACPICA maillist [email protected])

I read these patches but not clear what the problem they solved. Could you add info in the log of each patch?

Thanks,
Lin Ming

#7 lore raw
Quoted 6 lines · Lin Ming
Quoted 5 lines · malattia(a)linux.it

Hi Robert,

Here is a series of patches that I've been carrying in the iasl Debian package for some time. They are all refreshed and reworked to apply cleanly on top of acpica-unix-20100528.

...

Quoted 9 lines

Hi,

Thanks for the patches.

(linux-acpi(a)vger.kernel.org is for linux-specific acpi dicussion. Better to post these patches to ACPICA maillist devel(a)acpica.org)

I read these patches but not clear what the problem they solved. Could you add info in the log of each patch?

Sure, thanks for the ML pointer too.

Signature · 2 lines
mattia
:wq!
#8 lore raw
In reply to [email protected]

OK, We will look closely at these. I'm moving my office this week, so please be patient.

Thanks,
Bob

Quoted 37 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Saturday, July 03, 2010 9:44 PM
To: Moore, Robert
Cc: Len Brown; [email protected]
Subject: [patch 0/5] iASL patches in Debian

Hi Robert,

Here is a series of patches that I've been carrying in the iasl Debian package for some time. They are all refreshed and reworked to apply cleanly on top of acpica-unix-20100528.
The series consists a couple of trivial patches to fix building on the FreeBSD and Hurd kernel flavours of Debian and some larger ones to enable compiling ASL on big endian architectures.
It would be great if you could apply the patches to your source tree and ship new release with this work included.
Let me know if you want me to run more tests or change something in the patches.

I tested building tests/misc/grammar.asl (plus a number or other DSDTs I have here) with the whole set applied and the results were identical on BE and LE machines as well as being identical to what a clean iasl produces on x86[1].
You can see build logs for all the architectures supported here:
https://buildd.debian.org/status/package.php?p=acpica-unix

Thanks

[1]: checked with (1) an hex dump of the AML file, (2) the C file generated with -tc and (3) by decompiling the AML to DSL on x86 and comparing the results.
As a side note pristine iasl on x86 sefaults when building test/misc/grammar.asl, with these patches applied it doesn't.

--
mattia

#9 lore raw
In reply to [email protected]

If you'd like to get ambitious, run the ASLTS suite on the big-endian machines.

Quoted 37 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Saturday, July 03, 2010 9:44 PM
To: Moore, Robert
Cc: Len Brown; [email protected]
Subject: [patch 0/5] iASL patches in Debian

Hi Robert,

Here is a series of patches that I've been carrying in the iasl Debian package for some time. They are all refreshed and reworked to apply cleanly on top of acpica-unix-20100528.
The series consists a couple of trivial patches to fix building on the FreeBSD and Hurd kernel flavours of Debian and some larger ones to enable compiling ASL on big endian architectures.
It would be great if you could apply the patches to your source tree and ship new release with this work included.
Let me know if you want me to run more tests or change something in the patches.

I tested building tests/misc/grammar.asl (plus a number or other DSDTs I have here) with the whole set applied and the results were identical on BE and LE machines as well as being identical to what a clean iasl produces on x86[1].
You can see build logs for all the architectures supported here:
https://buildd.debian.org/status/package.php?p=acpica-unix

Thanks

[1]: checked with (1) an hex dump of the AML file, (2) the C file generated with -tc and (3) by decompiling the AML to DSL on x86 and comparing the results.
As a side note pristine iasl on x86 sefaults when building test/misc/grammar.asl, with these patches applied it doesn't.

--
mattia

#10 lore raw
Quoted 1 line · Robert

If you'd like to get ambitious, run the ASLTS suite on the big-endian machines.

I'll give it a go :)
Is the one found in the meego git repository what I should try?

Just one note that probably was not clear from my initial email: the patches I sent to support BE architectures are only for compiling asl code.
I'd like to add support for decompiling too eventually.

Thanks!

Quoted 37 lines
Quoted 37 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Saturday, July 03, 2010 9:44 PM
To: Moore, Robert
Cc: Len Brown; [email protected]
Subject: [patch 0/5] iASL patches in Debian

Hi Robert,

Here is a series of patches that I've been carrying in the iasl Debian package for some time. They are all refreshed and reworked to apply cleanly on top of acpica-unix-20100528.
The series consists a couple of trivial patches to fix building on the FreeBSD and Hurd kernel flavours of Debian and some larger ones to enable compiling ASL on big endian architectures.
It would be great if you could apply the patches to your source tree and ship new release with this work included.
Let me know if you want me to run more tests or change something in the patches.

I tested building tests/misc/grammar.asl (plus a number or other DSDTs I have here) with the whole set applied and the results were identical on BE and LE machines as well as being identical to what a clean iasl produces on x86[1].
You can see build logs for all the architectures supported here:
https://buildd.debian.org/status/package.php?p=acpica-unix

Thanks

[1]: checked with (1) an hex dump of the AML file, (2) the C file generated with -tc and (3) by decompiling the AML to DSL on x86 and comparing the results.
As a side note pristine iasl on x86 sefaults when building test/misc/grammar.asl, with these patches applied it doesn't.

--
mattia

Signature · 2 lines
mattia
:wq!
#11 lore raw

Then be sure to disable the disassembler with an appropriate error message on these architectures.

Note, we now have a data table compiler, you should look at that also.

Quoted 62 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, July 07, 2010 3:08 PM
To: Moore, Robert
Cc: Len Brown; [email protected]
Subject: Re: [patch 0/5] iASL patches in Debian

Quoted 1 line · Robert

If you'd like to get ambitious, run the ASLTS suite on the big-endian

machines.

I'll give it a go :)
Is the one found in the meego git repository what I should try?

Just one note that probably was not clear from my initial email: the patches I sent to support BE architectures are only for compiling asl code.
I'd like to add support for decompiling too eventually.

Thanks!

Quoted 7 lines
Quoted 7 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Saturday, July 03, 2010 9:44 PM
To: Moore, Robert
Cc: Len Brown; [email protected]
Subject: [patch 0/5] iASL patches in Debian

Quoted 7 lines
Quoted 7 lines

Hi Robert,

Here is a series of patches that I've been carrying in the iasl Debian package for some time. They are all refreshed and reworked to apply cleanly on top of acpica-unix-20100528.
The series consists a couple of trivial patches to fix building on the FreeBSD and Hurd kernel flavours of Debian and some larger ones to

enable

Quoted 15 lines
Quoted 15 lines

compiling ASL on big endian architectures.
It would be great if you could apply the patches to your source tree and ship new release with this work included.
Let me know if you want me to run more tests or change something in the patches.

I tested building tests/misc/grammar.asl (plus a number or other DSDTs I have here) with the whole set applied and the results were identical on BE and LE machines as well as being identical to what a clean iasl produces on x86[1].
You can see build logs for all the architectures supported here:
https://buildd.debian.org/status/package.php?p=acpica-unix

Thanks

Quoted 8 lines
Quoted 8 lines

[1]: checked with (1) an hex dump of the AML file, (2) the C file generated with -tc and (3) by decompiling the AML to DSL on x86 and comparing the results.
As a side note pristine iasl on x86 sefaults when building test/misc/grammar.asl, with these patches applied it doesn't.

--
mattia

--
mattia
:wq!

#14 lore raw
In reply to [email protected]
Quoted 5 lines · On Thu, 2010-07-08 at 06:07 +0800, [email protected] wrote:
Quoted 1 line · Robert

If you'd like to get ambitious, run the ASLTS suite on the big-endian machines.

I'll give it a go :)
Is the one found in the meego git repository what I should try?

Or acpica git repository (git://git.moblin.org/acpica)

acpica/tests/aslts

#12 lore raw
In reply to Moore, Robert
Quoted 2 lines · Robert

Then be sure to disable the disassembler with an appropriate error message on these architectures.

Right, makes sense.
It may take a few more days before I get the time to get back to digging into iasl code, I'll see if it's not too hard to support disassembling before doing as you suggests.

Quoted 1 line

Note, we now have a data table compiler, you should look at that also.

sure, any pointer to a starting point? :)

Thanks!

Signature · 2 lines
mattia
:wq!
#15 lore raw
In reply to Lin Ming
Quoted 10 lines · Lin Ming
Quoted 5 lines · On Thu, 2010-07-08 at 06:07 +0800, [email protected] wrote:
Quoted 1 line · Robert

If you'd like to get ambitious, run the ASLTS suite on the big-endian machines.

I'll give it a go :)
Is the one found in the meego git repository what I should try?

Or acpica git repository (git://git.moblin.org/acpica)

acpica/tests/aslts

For now I only ran "Do 0 aslts" and the results are not too bad. I cleaned up the build logs a bit and here's the diff between sparc64 and x86_64:

proc/self/fd/13 renamed from proc/self/fd/11 +9 -5
@@ -1,6 +1,10 @@
-Linux smetana 2.6.26-2-sparc64-smp #1 SMP Mon Jun 21 16:31:11 UTC 2010 sparc64 GNU/Linux
+Linux caligola 2.6.34 #37 SMP PREEMPT Sat May 29 11:36:03 JST 2010 x86_64 GNU/Linux
 
 Make-install all the provided test cases
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/64
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/64
 ASL Input:  MAIN.asl - 78 lines, 1734433 bytes, 21705 keywords
 AML Output: bdemo.aml - 282587 bytes, 4188 named objects, 17517 executable opcodes
 
@@ -90,11 +94,11 @@
 
 Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 0 Optimizations
 ASL Input:  MAIN.asl - 62 lines, 962044 bytes, 20265 keywords
-AML Output: oconst.aml - 255557 bytes, 862 named objects, 19403 executable opcodes
+AML Output: oconst.aml - 255575 bytes, 862 named objects, 19403 executable opcodes
 
 Compilation complete. 0 Errors, 1852 Warnings, 18 Remarks, 7775 Optimizations
 ASL Input:  MAIN.asl - 62 lines, 962044 bytes, 20265 keywords
-AML Output: oconst.aml - 261267 bytes, 862 named objects, 19403 executable opcodes
+AML Output: oconst.aml - 261272 bytes, 862 named objects, 19403 executable opcodes
 
 Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 7908 Optimizations
 ASL Input:  MAIN.asl - 66 lines, 256106 bytes, 3194 keywords
@@ -666,11 +670,11 @@
 
 Compilation complete. 0 Errors, 127 Warnings, 10 Remarks, 0 Optimizations
 ASL Input:  MAIN.asl - 71 lines, 229960 bytes, 4885 keywords
-AML Output: dynobj.aml - 57915 bytes, 599 named objects, 4286 executable opcodes
+AML Output: dynobj.aml - 57916 bytes, 599 named objects, 4286 executable opcodes
 
 Compilation complete. 0 Errors, 129 Warnings, 10 Remarks, 2101 Optimizations
 ASL Input:  MAIN.asl - 71 lines, 229960 bytes, 4885 keywords
-AML Output: dynobj.aml - 57919 bytes, 599 named objects, 4286 executable opcodes
+AML Output: dynobj.aml - 57920 bytes, 599 named objects, 4286 executable opcodes
 
 Compilation complete. 0 Errors, 127 Warnings, 10 Remarks, 2101 Optimizations
 ASL Input:  MAIN.asl - 60 lines, 94913 bytes, 1410 keywords

Looks like I have some more work to do ;)

Signature · 2 lines
mattia
:wq!
#16 lore raw
Quoted 8 lines · On Thu, 2010-07-08 at 21:49 +0800, [email protected] wrote:
Quoted 7 lines · Lin Ming
Quoted 5 lines · On Thu, 2010-07-08 at 06:07 +0800, [email protected] wrote:
Quoted 1 line · Robert

If you'd like to get ambitious, run the ASLTS suite on the big-endian machines.

I'll give it a go :)
Is the one found in the meego git repository what I should try?

Quoted 6 lines
Quoted 3 lines

Or acpica git repository (git://git.moblin.org/acpica)

acpica/tests/aslts

For now I only ran "Do 0 aslts" and the results are not too bad. I cleaned up the build logs a bit and here's the diff between sparc64 and x86_64:

Good. Thanks!

Quoted 16 lines
proc/self/fd/13 renamed from proc/self/fd/11 +5 -1
@@ -1,6 +1,10 @@
-Linux smetana 2.6.26-2-sparc64-smp #1 SMP Mon Jun 21 16:31:11 UTC 2010 sparc64 GNU/Linux
+Linux caligola 2.6.34 #37 SMP PREEMPT Sat May 29 11:36:03 JST 2010 x86_64 GNU/Linux
 
 Make-install all the provided test cases
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/64
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/64
 ASL Input:  MAIN.asl - 78 lines, 1734433 bytes, 21705 keywords
 AML Output: bdemo.aml - 282587 bytes, 4188 named objects, 17517 executable opcodes
 

proc/self/fd/13 line 97

Quoted 5 lines
proc/self/fd/13 renamed from proc/self/fd/11 +1 -1
@@ -90,11 +94,11 @@
 
 Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 0 Optimizations
 ASL Input:  MAIN.asl - 62 lines, 962044 bytes, 20265 keywords
-AML Output: oconst.aml - 255557 bytes, 862 named objects, 19403 executable opcodes
+AML Output: oconst.aml - 255575 bytes, 862 named objects, 19403 executable opcodes

Why do the aml files have different size?
Is it caused by big/small endian?

Lin Ming

Quoted 24 lines
proc/self/fd/13 renamed from proc/self/fd/11 +3 -3
 Compilation complete. 0 Errors, 1852 Warnings, 18 Remarks, 7775 Optimizations
 ASL Input:  MAIN.asl - 62 lines, 962044 bytes, 20265 keywords
-AML Output: oconst.aml - 261267 bytes, 862 named objects, 19403 executable opcodes
+AML Output: oconst.aml - 261272 bytes, 862 named objects, 19403 executable opcodes
 
 Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 7908 Optimizations
 ASL Input:  MAIN.asl - 66 lines, 256106 bytes, 3194 keywords
@@ -666,11 +670,11 @@
 
 Compilation complete. 0 Errors, 127 Warnings, 10 Remarks, 0 Optimizations
 ASL Input:  MAIN.asl - 71 lines, 229960 bytes, 4885 keywords
-AML Output: dynobj.aml - 57915 bytes, 599 named objects, 4286 executable opcodes
+AML Output: dynobj.aml - 57916 bytes, 599 named objects, 4286 executable opcodes
 
 Compilation complete. 0 Errors, 129 Warnings, 10 Remarks, 2101 Optimizations
 ASL Input:  MAIN.asl - 71 lines, 229960 bytes, 4885 keywords
-AML Output: dynobj.aml - 57919 bytes, 599 named objects, 4286 executable opcodes
+AML Output: dynobj.aml - 57920 bytes, 599 named objects, 4286 executable opcodes
 
 Compilation complete. 0 Errors, 127 Warnings, 10 Remarks, 2101 Optimizations
 ASL Input:  MAIN.asl - 60 lines, 94913 bytes, 1410 keywords

Looks like I have some more work to do ;)

#13 lore raw
In reply to [email protected]
Quoted 4 lines · On Thu, 2010-07-08 at 21:41 +0800, [email protected] wrote:
Quoted 2 lines · Robert

Then be sure to disable the disassembler with an appropriate error message on these architectures.

Quoted 8 lines

Right, makes sense.
It may take a few more days before I get the time to get back to digging into iasl code, I'll see if it's not too hard to support disassembling before doing as you suggests.

Quoted 1 line

Note, we now have a data table compiler, you should look at that also.

sure, any pointer to a starting point? :)

We have a nice document, see
http://www.acpica.org/download/aslcompiler.pdf

Section 2.4 Data Table Compiler

Quoted 2 lines

Thanks!

#17 lore raw
In reply to Lin Ming
Quoted 35 lines · Lin Ming
Quoted 8 lines · On Thu, 2010-07-08 at 21:49 +0800, [email protected] wrote:
Quoted 7 lines · Lin Ming
Quoted 5 lines · On Thu, 2010-07-08 at 06:07 +0800, [email protected] wrote:
Quoted 1 line · Robert

If you'd like to get ambitious, run the ASLTS suite on the big-endian machines.

I'll give it a go :)
Is the one found in the meego git repository what I should try?

Quoted 6 lines
Quoted 3 lines

Or acpica git repository (git://git.moblin.org/acpica)

acpica/tests/aslts

For now I only ran "Do 0 aslts" and the results are not too bad. I cleaned up the build logs a bit and here's the diff between sparc64 and x86_64:

Good. Thanks!

Quoted 17 lines
proc/self/fd/13 renamed from proc/self/fd/11 +5 -1
@@ -1,6 +1,10 @@
-Linux smetana 2.6.26-2-sparc64-smp #1 SMP Mon Jun 21 16:31:11 UTC 2010 sparc64 GNU/Linux
+Linux caligola 2.6.34 #37 SMP PREEMPT Sat May 29 11:36:03 JST 2010 x86_64 GNU/Linux
 
 Make-install all the provided test cases
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/64
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/64
 ASL Input:  MAIN.asl - 78 lines, 1734433 bytes, 21705 keywords
 AML Output: bdemo.aml - 282587 bytes, 4188 named objects, 17517 executable opcodes
 
@@ -90,11 +94,11 @@
 
Quoted 7 lines

proc/self/fd/13 line 97

Quoted 4 lines
proc/self/fd/13 renamed from proc/self/fd/11 +1 -1
 Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 0 Optimizations
 ASL Input:  MAIN.asl - 62 lines, 962044 bytes, 20265 keywords
-AML Output: oconst.aml - 255557 bytes, 862 named objects, 19403 executable opcodes
+AML Output: oconst.aml - 255575 bytes, 862 named objects, 19403 executable opcodes

Why do the aml files have different size?
Is it caused by big/small endian?

They should be identical, possibly my patch is incomplete or not correct. Out of the ~180 tests only the ones in the diff show differences.
I'll have to check what is wrong on sparc64 for them.

...

Quoted 3 lines
Quoted 3 lines
proc/self/fd/13 renamed from proc/self/fd/11 +3 -0
+AML Output: oconst.aml - 261272 bytes, 862 named objects, 19403 executable opcodes
+AML Output: dynobj.aml - 57916 bytes, 599 named objects, 4286 executable opcodes
+AML Output: dynobj.aml - 57920 bytes, 599 named objects, 4286 executable opcodes
Signature · 2 lines
mattia
:wq!
#20 lore raw
In reply to Lin Ming

Output files should (and must) be identical. ACPI tables are not endian-specific.

Quoted 95 lines

-----Original Message-----
From: Lin, Ming M
Sent: Thursday, July 08, 2010 3:07 PM
To: [email protected]
Cc: Moore, Robert; Len Brown; [email protected]
Subject: Re: [patch 0/5] iASL patches in Debian

Quoted 4 lines · On Thu, 2010-07-08 at 21:49 +0800, [email protected] wrote:
Quoted 3 lines · Lin Ming
Quoted 2 lines · On Thu, 2010-07-08 at 06:07 +0800, [email protected] wrote:
Quoted 1 line · Robert

If you'd like to get ambitious, run the ASLTS suite on the big-

endian machines.

Quoted 9 lines
Quoted 7 lines
Quoted 3 lines

I'll give it a go :)
Is the one found in the meego git repository what I should try?

Or acpica git repository (git://git.moblin.org/acpica)

acpica/tests/aslts

For now I only ran "Do 0 aslts" and the results are not too bad. I

cleaned

Quoted 1 line

up the build logs a bit and here's the diff between sparc64 and x86_64:

Good. Thanks!

proc/self/fd/13 line 1

Quoted 5 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -1
@@ -1,6 +1,10 @@
-Linux smetana 2.6.26-2-sparc64-smp #1 SMP Mon Jun 21 16:31:11 UTC 2010

sparc64 GNU/Linux

proc/self/fd/13 line 1

Quoted 1 line
proc/self/fd/13 renamed from proc/self/fd/11 +1 -0
+Linux caligola 2.6.34 #37 SMP PREEMPT Sat May 29 11:36:03 JST 2010

x86_64 GNU/Linux

proc/self/fd/13

Quoted 8 lines
proc/self/fd/13 renamed from proc/self/fd/11 +4 -0
 Make-install all the provided test cases
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/64
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/64
 ASL Input:  MAIN.asl - 78 lines, 1734433 bytes, 21705 keywords
 AML Output: bdemo.aml - 282587 bytes, 4188 named objects, 17517

executable opcodes

proc/self/fd/13 line 93

Quoted 6 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -1
@@ -90,11 +94,11 @@
 
 Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 0 Optimizations
 ASL Input:  MAIN.asl - 62 lines, 962044 bytes, 20265 keywords
-AML Output: oconst.aml - 255557 bytes, 862 named objects, 19403

executable opcodes

proc/self/fd/13 line 97

Quoted 1 line
proc/self/fd/13 renamed from proc/self/fd/11 +1 -0
+AML Output: oconst.aml - 255575 bytes, 862 named objects, 19403

executable opcodes

Why do the aml files have different size?
Is it caused by big/small endian?

Lin Ming

proc/self/fd/13 line 98

Quoted 2 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -0
 Compilation complete. 0 Errors, 1852 Warnings, 18 Remarks, 7775

Optimizations

proc/self/fd/13 line 96

Quoted 2 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -1
 ASL Input:  MAIN.asl - 62 lines, 962044 bytes, 20265 keywords
-AML Output: oconst.aml - 261267 bytes, 862 named objects, 19403

executable opcodes

proc/self/fd/13 line 100

Quoted 1 line
proc/self/fd/13 renamed from proc/self/fd/11 +1 -0
+AML Output: oconst.aml - 261272 bytes, 862 named objects, 19403

executable opcodes

proc/self/fd/13 line 101

Quoted 2 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -0
 Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 7908

Optimizations

proc/self/fd/13 line 671

Quoted 4 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -0
 ASL Input:  MAIN.asl - 66 lines, 256106 bytes, 3194 keywords
@@ -666,11 +670,11 @@
 
 Compilation complete. 0 Errors, 127 Warnings, 10 Remarks, 0

Optimizations

proc/self/fd/13 line 669

Quoted 2 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -1
 ASL Input:  MAIN.asl - 71 lines, 229960 bytes, 4885 keywords
-AML Output: dynobj.aml - 57915 bytes, 599 named objects, 4286 executable

opcodes

proc/self/fd/13 line 673

Quoted 1 line
proc/self/fd/13 renamed from proc/self/fd/11 +1 -0
+AML Output: dynobj.aml - 57916 bytes, 599 named objects, 4286 executable

opcodes

proc/self/fd/13 line 674

Quoted 2 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -0
 Compilation complete. 0 Errors, 129 Warnings, 10 Remarks, 2101

Optimizations

proc/self/fd/13 line 672

Quoted 2 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -1
 ASL Input:  MAIN.asl - 71 lines, 229960 bytes, 4885 keywords
-AML Output: dynobj.aml - 57919 bytes, 599 named objects, 4286 executable

opcodes

proc/self/fd/13 line 676

Quoted 1 line
proc/self/fd/13 renamed from proc/self/fd/11 +1 -0
+AML Output: dynobj.aml - 57920 bytes, 599 named objects, 4286 executable

opcodes

proc/self/fd/13 line 677

Quoted 2 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -0
 Compilation complete. 0 Errors, 127 Warnings, 10 Remarks, 2101

Optimizations

Quoted 3 lines
proc/self/fd/13 renamed from proc/self/fd/11 +0 -0
 ASL Input:  MAIN.asl - 60 lines, 94913 bytes, 1410 keywords
 
 Looks like I have some more work to do ;)
#18 lore raw
In reply to [email protected]
Quoted 44 lines · On Thu, 2010-07-08 at 22:40 +0800, [email protected] wrote:
Quoted 35 lines · Lin Ming
Quoted 8 lines · On Thu, 2010-07-08 at 21:49 +0800, [email protected] wrote:
Quoted 7 lines · Lin Ming
Quoted 5 lines · On Thu, 2010-07-08 at 06:07 +0800, [email protected] wrote:
Quoted 1 line · Robert

If you'd like to get ambitious, run the ASLTS suite on the big-endian machines.

I'll give it a go :)
Is the one found in the meego git repository what I should try?

Quoted 6 lines
Quoted 3 lines

Or acpica git repository (git://git.moblin.org/acpica)

acpica/tests/aslts

For now I only ran "Do 0 aslts" and the results are not too bad. I cleaned up the build logs a bit and here's the diff between sparc64 and x86_64:

Good. Thanks!

Quoted 17 lines
proc/self/fd/13 renamed from proc/self/fd/11 +5 -1
@@ -1,6 +1,10 @@
-Linux smetana 2.6.26-2-sparc64-smp #1 SMP Mon Jun 21 16:31:11 UTC 2010 sparc64 GNU/Linux
+Linux caligola 2.6.34 #37 SMP PREEMPT Sat May 29 11:36:03 JST 2010 x86_64 GNU/Linux
 
 Make-install all the provided test cases
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/nopt/64
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/32
+install -d -m 775 ../../../../../../tmp/aml/20100528/opt/64
 ASL Input:  MAIN.asl - 78 lines, 1734433 bytes, 21705 keywords
 AML Output: bdemo.aml - 282587 bytes, 4188 named objects, 17517 executable opcodes
 
@@ -90,11 +94,11 @@
 
Quoted 7 lines

proc/self/fd/13 line 97

Quoted 4 lines
proc/self/fd/13 renamed from proc/self/fd/11 +1 -1
 Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 0 Optimizations
 ASL Input:  MAIN.asl - 62 lines, 962044 bytes, 20265 keywords
-AML Output: oconst.aml - 255557 bytes, 862 named objects, 19403 executable opcodes
+AML Output: oconst.aml - 255575 bytes, 862 named objects, 19403 executable opcodes

Why do the aml files have different size?
Is it caused by big/small endian?

Quoted 4 lines

They should be identical, possibly my patch is incomplete or not correct. Out of the ~180 tests only the ones in the diff show differences.
I'll have to check what is wrong on sparc64 for them.

Hi,

Did you find out why they are different?

You can disassemble the aml files and see what the differences are.

Thanks,
Lin Ming

Quoted 5 lines

...

Quoted 3 lines
Quoted 3 lines
proc/self/fd/13 renamed from proc/self/fd/11 +3 -0
+AML Output: oconst.aml - 261272 bytes, 862 named objects, 19403 executable opcodes
+AML Output: dynobj.aml - 57916 bytes, 599 named objects, 4286 executable opcodes
+AML Output: dynobj.aml - 57920 bytes, 599 named objects, 4286 executable opcodes
#19 lore raw
Quoted 2 lines · Lin Ming
Quoted 1 line · On Thu, 2010-07-08 at 22:40 +0800, [email protected] wrote:

On Thu, Jul 08, 2010 at 10:06:47PM +0000, Lin Ming wrote:

...

Quoted 13 lines
Quoted 8 lines
Quoted 7 lines

proc/self/fd/13 line 97

Quoted 4 lines

Compilation complete. 0 Errors, 83 Warnings, 18 Remarks, 0 Optimizations ASL Input: MAIN.asl - 62 lines, 962044 bytes, 20265 keywords

proc/self/fd/13 renamed from proc/self/fd/11 +1 -1
-AML Output: oconst.aml - 255557 bytes, 862 named objects, 19403 executable opcodes
+AML Output: oconst.aml - 255575 bytes, 862 named objects, 19403 executable opcodes

Why do the aml files have different size?
Is it caused by big/small endian?

Quoted 4 lines

They should be identical, possibly my patch is incomplete or not correct. Out of the ~180 tests only the ones in the diff show differences.
I'll have to check what is wrong on sparc64 for them.

Quoted 5 lines

Hi,

Did you find out why they are different?

You can disassemble the aml files and see what the differences are.

haven't had the time to go after it yet. apologies.

But on a separate note, I assume there is interest in applying the patches to the upstream tree (at least once they are complete).

Thanks!

Signature · 2 lines
mattia
:wq!