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
