Bug#401153: backtrace for iasl bug #401153
found 401153 20060912-2 thanks On Mon, 2006-12-04 at 19:53:49 +0100, Andreas Barth wrote: * Andreas Henriksson ([EMAIL PROTECTED]) [061204 19:44]: I can confirm that the patch provided by Guillem Jover seems to fix the testcase in the original bug-report for me on Debian Testing PowerPC. I would propose to upload the fixed package ASAP. In case you want, I can do an NMU as well. Maybe I was not clear enough in my initial analysis, but this patch was a partial fix, which just solved the segmentation fault, the remaning problem is that the output is bogus, some of it needs to be swapped on big-endian boxes to be little-endian. I'd say that's even worse than the segfault as people may end up flashing bogus acpi data to their proms! regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#401153: backtrace for iasl bug #401153
Processing commands for [EMAIL PROTECTED]: found 401153 20060912-2 Bug#401153: iasl segfaults on powerpc Bug marked as found in version 20060912-2. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
* Guillem Jover ([EMAIL PROTECTED]) [061212 10:17]: found 401153 20060912-2 thanks On Mon, 2006-12-04 at 19:53:49 +0100, Andreas Barth wrote: * Andreas Henriksson ([EMAIL PROTECTED]) [061204 19:44]: I can confirm that the patch provided by Guillem Jover seems to fix the testcase in the original bug-report for me on Debian Testing PowerPC. I would propose to upload the fixed package ASAP. In case you want, I can do an NMU as well. Maybe I was not clear enough in my initial analysis, but this patch was a partial fix, which just solved the segmentation fault, the remaning problem is that the output is bogus, some of it needs to be swapped on big-endian boxes to be little-endian. I'd say that's even worse than the segfault as people may end up flashing bogus acpi data to their proms! Agreed. Thanks for clarification. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
We've never had a request to run iASl on big-endian machines, so I'm not surprised that it doesn't work. Bob -Original Message- From: Guillem Jover [mailto:[EMAIL PROTECTED] Sent: Sunday, December 03, 2006 10:59 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Mattia Dongili; Andreas Henriksson; Moore, Robert Subject: Re: Bug#401153: backtrace for iasl bug #401153 Hi, Mattia I'm sorry you got this, after I asked to enable iasl on all arches to be able to use it in qemu. I started investigating this last week or so, but didn't file a bug report because I've not come yet with a complete solution. Below my current analysis anyway, if I've time I'll try to come up with a full fix... On Sun, 2006-12-03 at 13:13:19 +0100, Mattia Dongili wrote: On Sat, Dec 02, 2006 at 02:27:40AM +0100, Andreas Henriksson wrote: On fre, 2006-12-01 at 15:43 -0800, Moore, Robert wrote: I'm not sure I understand what you are describing, please clarify. Please see http://bugs.debian.org/401153 for the original bug report. Basically, iasl successfully compiles the atteched dsl file on a regular i386 pc, but when running the same program on PowerPC (Debian GNU/Linux) then you get a segmentation fault. There is probably a bug in the program somewhere which seems to only trigger on powerpc at the moment. It has been tracked down to being related to Asl.Value.String being NULL. This state seems invalid and makes the program crash. Do you have any idea what might have failed and how this variable could be uninitialized? It would be really appreciated if you have any hints about possible failures that we can investigate... This is a problem of endinaness. iasl does not work on big-endian boxes. The main issue is that the bison parser is using Value.Integer (which is an ACPI_INTEGER and in 32 bit arches it's a 64 bit type) to assign the values to the union ACPI_PARSE_VALUE. And then when accessing the pointers or the 'Size' variable it gets only the MSW, which is 0, so my workaround has been to define that we cannot use a 64 bit type for ACPI_INTEGER on 32 bit arches. Ideally the union should be filled using the proper member. This fixes the segfault. There's mentions in the changes.txt from 2003 of added support for big-endian systems, which was the first thing I tried, to enable the ACPI_BIG_ENDIAN macro for those arches (that's included in the patch anyway), but this didn't help. I suppose the code has evolved since then and that support has been lost because no one run it on such arches. Then the next problem is that iasl generates output, but that output is wrong. The output needs to be swapped to make it little-endian. AFAIS the problem is located in compiler/aslcodegen.c in most of the functions that are using CgLocalWriteAmlData, as they should be converting those values to little-endian when writting. But it didn't feel right to keep the TableHeader stored as little-endian in memory, as some other parts of the code use and reference it. So problably this needs to be swapped when dumping to the disk. Just as a side note, I tried compiling the mentioned DSDT on an ARM platform and I get a different error: I was trying it on arm little endian and it worked, the same for mipsel. The attached patch fixes the segfault, and corrects the CFLAGS handling for upstream and Debian, it also adds alpha to the list of 64 bit arches. The fix for compiler/aslopcodes.c is needed because the macros ACPI_UINT32_MAX: and ACPI_INTEGER_MAX are the same if ACPI_INTEGER is defined to be 32 bits. regards, guillem
Bug#401153: backtrace for iasl bug #401153
On Mon, Dec 04, 2006 at 04:38:26PM +0100, Andreas Henriksson wrote: On Sun, Dec 03, 2006 at 08:58:31PM +0200, Guillem Jover wrote: [...] The attached patch fixes the segfault, and corrects the CFLAGS handling for upstream and Debian, it also adds alpha to the list of 64 bit arches. The fix for compiler/aslopcodes.c is needed because the macros ACPI_UINT32_MAX: and ACPI_INTEGER_MAX are the same if ACPI_INTEGER is defined to be 32 bits. regards, guillem I can confirm that the patch provided by Guillem Jover seems to fix the testcase in the original bug-report for me on Debian Testing PowerPC. $ iasl -tc ../acpi-dsdt.dsl Intel ACPI Component Architecture ASL Optimizing Compiler version 20060912 [Dec 4 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a ASL Input: ../acpi-dsdt.dsl - 561 lines, 18338 bytes, 209 keywords AML Output: acpi-dsdt.aml - 2098 bytes 104 named objects 105 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 68 Optimizations $ Ok, I'll see if it doesn't introduce evident regressions (eg by compiling some of the DSDT's available on acpi.sf.net + my own here) and eventually include it in the package. Robert: does the patch looks correct to you? Thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On Sun, Dec 03, 2006 at 08:58:31PM +0200, Guillem Jover wrote: [...] The attached patch fixes the segfault, and corrects the CFLAGS handling for upstream and Debian, it also adds alpha to the list of 64 bit arches. The fix for compiler/aslopcodes.c is needed because the macros ACPI_UINT32_MAX: and ACPI_INTEGER_MAX are the same if ACPI_INTEGER is defined to be 32 bits. regards, guillem I can confirm that the patch provided by Guillem Jover seems to fix the testcase in the original bug-report for me on Debian Testing PowerPC. $ iasl -tc ../acpi-dsdt.dsl Intel ACPI Component Architecture ASL Optimizing Compiler version 20060912 [Dec 4 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a ASL Input: ../acpi-dsdt.dsl - 561 lines, 18338 bytes, 209 keywords AML Output: acpi-dsdt.aml - 2098 bytes 104 named objects 105 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 68 Optimizations $ Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
* Andreas Henriksson ([EMAIL PROTECTED]) [061204 19:44]: I can confirm that the patch provided by Guillem Jover seems to fix the testcase in the original bug-report for me on Debian Testing PowerPC. I would propose to upload the fixed package ASAP. In case you want, I can do an NMU as well. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On Mon, Dec 04, 2006 at 07:53:49PM +0100, Andreas Barth wrote: * Andreas Henriksson ([EMAIL PROTECTED]) [061204 19:44]: I can confirm that the patch provided by Guillem Jover seems to fix the testcase in the original bug-report for me on Debian Testing PowerPC. I would propose to upload the fixed package ASAP. In case you want, I can do an NMU as well. No problem, I'm already working on it. Thanks. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On Sat, Dec 02, 2006 at 02:27:40AM +0100, Andreas Henriksson wrote: On fre, 2006-12-01 at 15:43 -0800, Moore, Robert wrote: I'm not sure I understand what you are describing, please clarify. Please see http://bugs.debian.org/401153 for the original bug report. Basically, iasl successfully compiles the atteched dsl file on a regular i386 pc, but when running the same program on PowerPC (Debian GNU/Linux) then you get a segmentation fault. There is probably a bug in the program somewhere which seems to only trigger on powerpc at the moment. It has been tracked down to being related to Asl.Value.String being NULL. This state seems invalid and makes the program crash. Do you have any idea what might have failed and how this variable could be uninitialized? It would be really appreciated if you have any hints about possible failures that we can investigate... Just as a side note, I tried compiling the mentioned DSDT on an ARM platform and I get a different error: $ ./acpica-unix-20060912/compiler/iasl acpi-dsdt.dsl Intel ACPI Component Architecture ASL Optimizing Compiler version 20060912 [Oct 2 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a ACPI Warning (nssearch-0421): Found bad character(s) in name, repaired: [_GP*] [20060912] And no AML is generated. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
Hi, Mattia I'm sorry you got this, after I asked to enable iasl on all arches to be able to use it in qemu. I started investigating this last week or so, but didn't file a bug report because I've not come yet with a complete solution. Below my current analysis anyway, if I've time I'll try to come up with a full fix... On Sun, 2006-12-03 at 13:13:19 +0100, Mattia Dongili wrote: On Sat, Dec 02, 2006 at 02:27:40AM +0100, Andreas Henriksson wrote: On fre, 2006-12-01 at 15:43 -0800, Moore, Robert wrote: I'm not sure I understand what you are describing, please clarify. Please see http://bugs.debian.org/401153 for the original bug report. Basically, iasl successfully compiles the atteched dsl file on a regular i386 pc, but when running the same program on PowerPC (Debian GNU/Linux) then you get a segmentation fault. There is probably a bug in the program somewhere which seems to only trigger on powerpc at the moment. It has been tracked down to being related to Asl.Value.String being NULL. This state seems invalid and makes the program crash. Do you have any idea what might have failed and how this variable could be uninitialized? It would be really appreciated if you have any hints about possible failures that we can investigate... This is a problem of endinaness. iasl does not work on big-endian boxes. The main issue is that the bison parser is using Value.Integer (which is an ACPI_INTEGER and in 32 bit arches it's a 64 bit type) to assign the values to the union ACPI_PARSE_VALUE. And then when accessing the pointers or the 'Size' variable it gets only the MSW, which is 0, so my workaround has been to define that we cannot use a 64 bit type for ACPI_INTEGER on 32 bit arches. Ideally the union should be filled using the proper member. This fixes the segfault. There's mentions in the changes.txt from 2003 of added support for big-endian systems, which was the first thing I tried, to enable the ACPI_BIG_ENDIAN macro for those arches (that's included in the patch anyway), but this didn't help. I suppose the code has evolved since then and that support has been lost because no one run it on such arches. Then the next problem is that iasl generates output, but that output is wrong. The output needs to be swapped to make it little-endian. AFAIS the problem is located in compiler/aslcodegen.c in most of the functions that are using CgLocalWriteAmlData, as they should be converting those values to little-endian when writting. But it didn't feel right to keep the TableHeader stored as little-endian in memory, as some other parts of the code use and reference it. So problably this needs to be swapped when dumping to the disk. Just as a side note, I tried compiling the mentioned DSDT on an ARM platform and I get a different error: I was trying it on arm little endian and it worked, the same for mipsel. The attached patch fixes the segfault, and corrects the CFLAGS handling for upstream and Debian, it also adds alpha to the list of 64 bit arches. The fix for compiler/aslopcodes.c is needed because the macros ACPI_UINT32_MAX: and ACPI_INTEGER_MAX are the same if ACPI_INTEGER is defined to be 32 bits. regards, guillem diff -ur acpica-unix-20060912.orig/compiler/aslopcodes.c acpica-unix-20060912/compiler/aslopcodes.c --- acpica-unix-20060912.orig/compiler/aslopcodes.c 2006-09-12 20:49:25.0 +0300 +++ acpica-unix-20060912/compiler/aslopcodes.c 2006-11-27 09:40:52.0 +0200 @@ -329,6 +329,7 @@ } break; +#ifndef ACPI_NO_INTEGER64_SUPPORT case ACPI_INTEGER_MAX: /* Check for table integer width (32 or 64) */ @@ -341,6 +342,7 @@ return 1; } break; +#endif default: break; diff -ur acpica-unix-20060912.orig/compiler/Makefile acpica-unix-20060912/compiler/Makefile --- acpica-unix-20060912.orig/compiler/Makefile 2006-09-12 20:49:26.0 +0300 +++ acpica-unix-20060912/compiler/Makefile 2006-11-27 06:48:01.0 +0200 @@ -89,7 +89,8 @@ ../osunixxf.c NOMAN= YES -CFLAGS+= -Wall -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER -I../include +MK_CFLAGS = -DACPI_ASL_COMPILER -I../include +CFLAGS= -Wall -Wstrict-prototypes -O2 #YACC= yacc YACC= bison @@ -103,6 +104,9 @@ #CFLAGS+= -D_USE_BERKELEY_YACC #.endif +%.o: %.c + $(CC) $(MK_CFLAGS) $(CFLAGS) -c -o $@ $ + aslmain : $(patsubst %.c,%.o, $(SRCS)) $(CC) $(LDFLAGS) $(patsubst %.c,%.o, $(SRCS)) \ $(LOADLIBES) $(LDLIBS) -o iasl diff -ur acpica-unix-20060912.orig/debian/rules acpica-unix-20060912/debian/rules --- acpica-unix-20060912.orig/debian/rules 2006-11-27 06:38:05.0 +0200 +++ acpica-unix-20060912/debian/rules 2006-11-27 06:40:31.0 +0200 @@ -32,7 +32,7 @@ # Commands to compile the package. cd compiler \ - $(MAKE) \ + $(MAKE) CFLAGS=$(CFLAGS) \ cd .. touch
Bug#401153: backtrace for iasl bug #401153
Program received signal SIGSEGV, Segmentation fault. 0x10019570 in TrAmlTransformWalk () (gdb) bt #0 0x10019570 in TrAmlTransformWalk () #1 0x1001758c in TrWalkParseTree () #2 0x1000b728 in CmDoCompile () #3 0x10011250 in main () (gdb) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On Fri, Dec 01, 2006 at 03:42:51PM +0100, Andreas Henriksson wrote: Program received signal SIGSEGV, Segmentation fault. 0x10019570 in TrAmlTransformWalk () (gdb) bt #0 0x10019570 in TrAmlTransformWalk () #1 0x1001758c in TrWalkParseTree () #2 0x1000b728 in CmDoCompile () #3 0x10011250 in main () (gdb) I forgot to mention, this is on Debian Testing PowerPC with iasl recompiled with DEB_BUILD_OPTIONS=noopt, nostrip. Some additional printf debugging shows this: TrAmlTransformWalk - TrTransformSubtree - TrDoDefinitionBlock File compiler/asltransform.c line 432: if (!ACPI_COMPARE_NAME (Next-Asl.Value.String, ACPI_SIG_DSDT)) it blows up here Next-Asl.Value.String is NULL... All the macro/pointer obfuscation got me lost here... HTH -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On Fri, Dec 01, 2006 at 04:45:37PM +0100, Andreas Henriksson wrote: On Fri, Dec 01, 2006 at 03:42:51PM +0100, Andreas Henriksson wrote: Program received signal SIGSEGV, Segmentation fault. 0x10019570 in TrAmlTransformWalk () (gdb) bt #0 0x10019570 in TrAmlTransformWalk () #1 0x1001758c in TrWalkParseTree () #2 0x1000b728 in CmDoCompile () #3 0x10011250 in main () (gdb) I forgot to mention, this is on Debian Testing PowerPC with iasl recompiled with DEB_BUILD_OPTIONS=noopt, nostrip. Some additional printf debugging shows this: TrAmlTransformWalk - TrTransformSubtree - TrDoDefinitionBlock File compiler/asltransform.c line 432: if (!ACPI_COMPARE_NAME (Next-Asl.Value.String, ACPI_SIG_DSDT)) it blows up here Next-Asl.Value.String is NULL... All the macro/pointer obfuscation got me lost here... Thanks, I'm forwading the thing upstream -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
Hi Robert, I've been submitted a bug from the powerpc Debian's folks (see below or point your browser at [1]). In short the story is: we enabled building iasl for powerpc in order to buld DSDT tables for qemu which is available on powerpc and can emulate the x86. So we have a DSDT which makes iasl segfault while building on powerpc, it doesn't on i386. The DSDT is here: http://bugs.debian.org/cgi-bin/bugreport.cgi/acpi-dsdt.dsl?bug=401153;msg=5;att=1 Can you help putting some light where the problem may hide? Thanks [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401153 - Forwarded message from Andreas Henriksson [EMAIL PROTECTED] - Subject: Bug#401153: backtrace for iasl bug #401153 From: Andreas Henriksson [EMAIL PROTECTED] Date: Fri, 1 Dec 2006 16:45:37 +0100 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] User-Agent: Mutt/1.5.9i Reply-To: Andreas Henriksson [EMAIL PROTECTED], [EMAIL PROTECTED] On Fri, Dec 01, 2006 at 03:42:51PM +0100, Andreas Henriksson wrote: Program received signal SIGSEGV, Segmentation fault. 0x10019570 in TrAmlTransformWalk () (gdb) bt #0 0x10019570 in TrAmlTransformWalk () #1 0x1001758c in TrWalkParseTree () #2 0x1000b728 in CmDoCompile () #3 0x10011250 in main () (gdb) I forgot to mention, this is on Debian Testing PowerPC with iasl recompiled with DEB_BUILD_OPTIONS=noopt, nostrip. Some additional printf debugging shows this: TrAmlTransformWalk - TrTransformSubtree - TrDoDefinitionBlock File compiler/asltransform.c line 432: if (!ACPI_COMPARE_NAME (Next-Asl.Value.String, ACPI_SIG_DSDT)) it blows up here Next-Asl.Value.String is NULL... All the macro/pointer obfuscation got me lost here... HTH -- Regards, Andreas Henriksson - End forwarded message - -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
On fre, 2006-12-01 at 15:43 -0800, Moore, Robert wrote: I'm not sure I understand what you are describing, please clarify. Please see http://bugs.debian.org/401153 for the original bug report. Basically, iasl successfully compiles the atteched dsl file on a regular i386 pc, but when running the same program on PowerPC (Debian GNU/Linux) then you get a segmentation fault. There is probably a bug in the program somewhere which seems to only trigger on powerpc at the moment. It has been tracked down to being related to Asl.Value.String being NULL. This state seems invalid and makes the program crash. Do you have any idea what might have failed and how this variable could be uninitialized? It would be really appreciated if you have any hints about possible failures that we can investigate... Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401153: backtrace for iasl bug #401153
I'm not sure I understand what you are describing, please clarify. The DSDT compiles on Windows OK: C:\Acpi\Bugs\faultiasl dsdt.dsl Intel ACPI Component Architecture ASL Optimizing Compiler version 20061109 [Nov 9 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a ASL Input: dsdt.dsl - 561 lines, 18338 bytes, 209 keywords AML Output: acpi-dsdt.aml - 2098 bytes 104 named objects 105 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 68 Optimizations -Original Message- From: Mattia Dongili [mailto:[EMAIL PROTECTED] Sent: Friday, December 01, 2006 11:16 AM To: Moore, Robert Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Andreas Henriksson Subject: Bug#401153: backtrace for iasl bug #401153 Hi Robert, I've been submitted a bug from the powerpc Debian's folks (see below or point your browser at [1]). In short the story is: we enabled building iasl for powerpc in order to buld DSDT tables for qemu which is available on powerpc and can emulate the x86. So we have a DSDT which makes iasl segfault while building on powerpc, it doesn't on i386. The DSDT is here: http://bugs.debian.org/cgi-bin/bugreport.cgi/acpi- dsdt.dsl?bug=401153;msg=5;att=1 Can you help putting some light where the problem may hide? Thanks [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401153 - Forwarded message from Andreas Henriksson [EMAIL PROTECTED] - Subject: Bug#401153: backtrace for iasl bug #401153 From: Andreas Henriksson [EMAIL PROTECTED] Date: Fri, 1 Dec 2006 16:45:37 +0100 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] User-Agent: Mutt/1.5.9i Reply-To: Andreas Henriksson [EMAIL PROTECTED], [EMAIL PROTECTED] On Fri, Dec 01, 2006 at 03:42:51PM +0100, Andreas Henriksson wrote: Program received signal SIGSEGV, Segmentation fault. 0x10019570 in TrAmlTransformWalk () (gdb) bt #0 0x10019570 in TrAmlTransformWalk () #1 0x1001758c in TrWalkParseTree () #2 0x1000b728 in CmDoCompile () #3 0x10011250 in main () (gdb) I forgot to mention, this is on Debian Testing PowerPC with iasl recompiled with DEB_BUILD_OPTIONS=noopt, nostrip. Some additional printf debugging shows this: TrAmlTransformWalk - TrTransformSubtree - TrDoDefinitionBlock File compiler/asltransform.c line 432: if (!ACPI_COMPARE_NAME (Next-Asl.Value.String, ACPI_SIG_DSDT)) it blows up here Next-Asl.Value.String is NULL... All the macro/pointer obfuscation got me lost here... HTH -- Regards, Andreas Henriksson - End forwarded message - -- mattia :wq!
