The ACPI Component Architecture (ACPICA) project provides an open-source operating system-independent implementation of the Advanced Configuration and Power Interface specification (ACPI). For detailed project information and downloads, go to https://www.acpica.org. For ACPICA contributor and source code licensing information, go to
Home Page: https://www.acpica.org/licensing
We have tried compiling 5696af5 with soon to be updated gcc-8.0 and it produces the following errors when compiling on DragonFly BSD:
../../../source/tools/acpiexec/aetables.c: In function 'AeInitializeTableHeader':
../../../source/tools/acpiexec/aetables.c:263:5: error: 'strncpy' output truncated before terminating nul copying 8 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy (Header->OemTableId, "AcpiExec", ACPI_OEM_TABLE_ID_SIZE);
../../../source/tools/acpiexec/aetables.c:264:5: error: 'strncpy' output truncated before terminating nul copying 4 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy (Header->AslCompilerId, "INTL", ACPI_NAME_SIZE);
cc1: all warnings being treated as errors
../../../source/tools/acpinames/antables.c: In function 'AnInitializeTableHeader':
../../../source/tools/acpinames/antables.c:214:5: error: 'strncpy' output truncated before terminating nul copying 8 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy (Header->OemTableId, "AcpiName", ACPI_OEM_TABLE_ID_SIZE);
../../../source/tools/acpinames/antables.c:215:5: error: 'strncpy' output truncated before terminating nul copying 4 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy (Header->AslCompilerId, "INTL", ACPI_NAME_SIZE);
cc1: all warnings being treated as errors
../../../source/compiler/aslanalyze.c: In function 'AnCheckMethodReturnValue':
../../../source/compiler/aslanalyze.c:467:17: error: '%s' directive writing up to 32767 bytes into a region of size 32752 [-Werror=format-overflow=]
"Method returns [%s], %s operator requires [%s]",
StringBuffer, OpInfo->Name, StringBuffer2);
../../../source/compiler/aslanalyze.c:466:13: note: 'sprintf' output 41 or more bytes (assuming 65575) into a destination of size 32768
sprintf (MsgBuffer,
"Method returns [%s], %s operator requires [%s]",
StringBuffer, OpInfo->Name, StringBuffer2);
cc1: all warnings being treated as errors
... more -Werror=format-overflow
To suppress -Wstringop-truncation warnings we are considering using memcpy():
memcpy (Header->OemTableId, "AcpiExec", ACPI_OEM_TABLE_ID_SIZE);
memcpy (Header->AslCompilerId, "INTL", ACPI_NAME_SIZE);
The order in which the disassembler writes unresolved Externals and Externals from the -fe option could be improved.
Currently, these Externals are written in their own section before the other resolved Externals (from -da option and other AML files). This exposes a problem the compiler has with order of Externals.
For example, this small example results in an error, "Name already exists in scope (FOO1)":
DefinitionBlock ("TEST.aml", "DSDT", 2, "TEST", "TEST", 0x000000)
{
External(FOO1.BAR1, MethodObj)
External(FOO1, DeviceObj)
}
If we reverse the order of two Externals, no error:
DefinitionBlock ("TEST.aml", "DSDT", 2, "TEST", "TEST", 0x000000)
{
External(FOO1, DeviceObj)
External(FOO1.BAR1, MethodObj)
}
I think what is happening here is in the case of External(FOO1.BAR1,MethodObj), FOO1 is entered with a type of unknown. When the compiler comes across External(FOO1,DeviceObj) instead of updating the type of the existing symbol, it issues an error.
This same problem shows up quite easily in disassembly of complex files, as the externals provided with the -fe option or unresolved externals tend to be leaf nodes. Since they appear first, the embedded parent nodes end up getting entered in the symbol table with unknown type, even though they later appear in the file as resolved symbols (because they are usually defined in DSDT or another SSDT, for example).
I've found that if the Externals are emitted in natural order, there is not a problem, as the Externals seem to be in a good order in the AcpiGbl_ExternalList.
These are the diffs (for the disassembler):
diff --git a/source/common/dmextern.c b/source/common/dmextern.c
index 229397f..9765d3d 100644
--- a/source/common/dmextern.c
+++ b/source/common/dmextern.c
@@ -1157,7 +1157,7 @@ AcpiDmEmitExternals (
if ((NextExternal->Type == ACPI_TYPE_METHOD) &&
(!(NextExternal->Flags & ACPI_EXT_RESOLVED_REFERENCE)))
{
- AcpiOsPrintf (" External (%s%s",
+ AcpiOsPrintf (" //External (%s%s",
NextExternal->Path,
AcpiDmGetObjectTypeName (NextExternal->Type));
@@ -1165,7 +1165,7 @@ AcpiDmEmitExternals (
"guessing %u arguments\n",
NextExternal->Value);
- NextExternal->Flags |= ACPI_EXT_EXTERNAL_EMITTED;
+ //NextExternal->Flags |= ACPI_EXT_EXTERNAL_EMITTED;
}
NextExternal = NextExternal->Next;
@@ -1189,7 +1189,7 @@ AcpiDmEmitExternals (
if (!(NextExternal->Flags & ACPI_EXT_EXTERNAL_EMITTED) &&
(NextExternal->Flags & ACPI_EXT_ORIGIN_FROM_FILE))
{
- AcpiOsPrintf (" External (%s%s",
+ AcpiOsPrintf (" //External (%s%s",
NextExternal->Path,
AcpiDmGetObjectTypeName (NextExternal->Type));
@@ -1202,7 +1202,7 @@ AcpiDmEmitExternals (
{
AcpiOsPrintf (")\n");
}
- NextExternal->Flags |= ACPI_EXT_EXTERNAL_EMITTED;
+ //NextExternal->Flags |= ACPI_EXT_EXTERNAL_EMITTED;
}
NextExternal = NextExternal->Next;
@@ -1226,12 +1226,36 @@ AcpiDmEmitExternals (
if (AcpiGbl_ExternalList->Type == ACPI_TYPE_METHOD)
{
- AcpiOsPrintf (") // %u Arguments\n",
- AcpiGbl_ExternalList->Value);
+ if (!(AcpiGbl_ExternalList->Flags & ACPI_EXT_RESOLVED_REFERENCE))
+ {
+ AcpiOsPrintf (") // Warning: Unresolved method, "
+ "guessing %u arguments\n",
+ AcpiGbl_ExternalList->Value);
+ }
+ else if (AcpiGbl_ExternalList->Flags & ACPI_EXT_ORIGIN_FROM_FILE)
+ {
+ AcpiOsPrintf (") // Imported: %u Arguments\n",
+ AcpiGbl_ExternalList->Value);
+ }
+ else
+ {
+ AcpiOsPrintf (")\n");
+ }
}
else
{
- AcpiOsPrintf (")\n");
+ if (!(AcpiGbl_ExternalList->Flags & ACPI_EXT_RESOLVED_REFERENCE))
+ {
+ AcpiOsPrintf (") // Warning: unresolved\n");
+ }
+ else if (AcpiGbl_ExternalList->Flags & ACPI_EXT_ORIGIN_FROM_FILE)
+ {
+ AcpiOsPrintf (") // Imported\n");
+ }
+ else
+ {
+ AcpiOsPrintf (")\n");
+ }
}
}
I left the separate sections in the output, but made them comments, and augmented the normal External output so unresolved and imported externals are identified. I also emit a comment for non-method unresolved externals as that is probably something to look into if one was trying to find ACPI problems...
I didn't look into allowing a type of "unknown" to be overwritten by an External declaration of known type (would be a compiler change). That may be a more desireable fix, depending on your perspective.
I seem to get a crash when parsing my laptops DSDT file. The output is the following:
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20170224
Copyright (c) 2000 - 2017 Intel Corporation
Input file dsdt/dsdt.dat, Length 0x19726 (104230) bytes
ACPI: DSDT 0x0000000000000000 019726 (v02 _ASUS_ Notebook 01072009 INTL 20120913)
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
Parsing completed
Found 2 external control methods, reparsing with new information
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
Parsing completed
*** Error in `iasl': munmap_chunk(): invalid pointer: 0x00000000004a76d5 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x722ab)[0x7fc2c692f2ab]
/usr/lib/libc.so.6(+0x7890e)[0x7fc2c693590e]
iasl[0x43b09b]
iasl[0x43ac88]
iasl[0x43ad38]
iasl[0x437670]
iasl[0x41215b]
iasl[0x429017]
iasl[0x4292d4]
iasl[0x401e9b]
/usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7fc2c68dd511]
iasl[0x401f4a]
======= Memory map: ========
00400000-004e1000 r-xp 00000000 b3:02 673194 /usr/bin/iasl
006e0000-006e1000 r--p 000e0000 b3:02 673194 /usr/bin/iasl
006e1000-006eb000 rw-p 000e1000 b3:02 673194 /usr/bin/iasl
006eb000-00705000 rw-p 00000000 00:00 0
00cff000-0131d000 rw-p 00000000 00:00 0 [heap]
7fc2c66a6000-7fc2c66bc000 r-xp 00000000 b3:02 656544 /usr/lib/libgcc_s.so.1
7fc2c66bc000-7fc2c68bb000 ---p 00016000 b3:02 656544 /usr/lib/libgcc_s.so.1
7fc2c68bb000-7fc2c68bc000 r--p 00015000 b3:02 656544 /usr/lib/libgcc_s.so.1
7fc2c68bc000-7fc2c68bd000 rw-p 00016000 b3:02 656544 /usr/lib/libgcc_s.so.1
7fc2c68bd000-7fc2c6a58000 r-xp 00000000 b3:02 654989 /usr/lib/libc-2.25.so
7fc2c6a58000-7fc2c6c57000 ---p 0019b000 b3:02 654989 /usr/lib/libc-2.25.so
7fc2c6c57000-7fc2c6c5b000 r--p 0019a000 b3:02 654989 /usr/lib/libc-2.25.so
7fc2c6c5b000-7fc2c6c5d000 rw-p 0019e000 b3:02 654989 /usr/lib/libc-2.25.so
7fc2c6c5d000-7fc2c6c61000 rw-p 00000000 00:00 0
7fc2c6c61000-7fc2c6c84000 r-xp 00000000 b3:02 654990 /usr/lib/ld-2.25.so
7fc2c6e53000-7fc2c6e55000 rw-p 00000000 00:00 0
7fc2c6e82000-7fc2c6e83000 rw-p 00000000 00:00 0
7fc2c6e83000-7fc2c6e84000 r--p 00022000 b3:02 654990 /usr/lib/ld-2.25.so
7fc2c6e84000-7fc2c6e85000 rw-p 00023000 b3:02 654990 /usr/lib/ld-2.25.so
7fc2c6e85000-7fc2c6e86000 rw-p 00000000 00:00 0
7ffe4a475000-7ffe4a496000 rw-p 00000000 00:00 0 [stack]
7ffe4a51f000-7ffe4a521000 r--p 00000000 00:00 0 [vvar]
7ffe4a521000-7ffe4a523000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
[1] 31795 abort (core dumped) iasl -d dsdt/dsdt.dat ssdt/* -e other/*
The files I was trying to parse are the following:
acpidump.tar.gz
The latest iasl 20180927 crashes on macOS due to double free when compiling this file: problematic.zip. This issue appears to be a regression, and does not happen with 20180810.
Here is a report with AddressSanitizer enabled showing the stacktrace of the crash and the allocation.
=================================================================
==1880==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x63100000b152 in thread T0
#0 0x1103a010d in wrap_free (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5710d)
#1 0x10fd400b8 in OptBuildShortestPath aslopt.c:525
#2 0x10fd3d10d in OptOptimizeNamePath aslopt.c
#3 0x10fd9d0e8 in XfNamespaceLocateBegin aslxref.c:779
#4 0x10fd93636 in TrWalkParseTree asltree.c:966
#5 0x10fd9b3d8 in XfCrossReferenceNamespace aslxref.c:240
#6 0x10fcf8729 in CmDoCompile aslcompile.c:378
#7 0x10fd85d6c in AslDoOneFile aslstartup.c:561
#8 0x10fd1e7dd in main aslmain.c:273
#9 0x7fff7d561014 in start (libdyld.dylib:x86_64+0x1014)
0x63100000b152 is located 43346 bytes inside of 65544-byte region [0x631000000800,0x631000010808)
allocated by thread T0 here:
#0 0x1103a0497 in wrap_calloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x57497)
#1 0x10fcec8ce in UtLocalCalloc aslallocate.c:185
#2 0x10fcf22e6 in UtLocalCacheCalloc aslcache.c:212
#3 0x10fce31d6 in FlStrdup adfile.c:361
#4 0x10fce300d in FlSplitInputPathname adfile.c:408
#5 0x10fd85afe in AslDoOneFile aslstartup.c:447
#6 0x10fd1e7dd in main aslmain.c:273
#7 0x7fff7d561014 in start (libdyld.dylib:x86_64+0x1014)
SUMMARY: AddressSanitizer: bad-free (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5710d) in wrap_free
==1880==ABORTING
Abort trap: 6
iasl -da *.dat DOES NOT WORK.
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d dsdt.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt1.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt2.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt3.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt4.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt5.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt6.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt7.dat
iasl -e ssdt1.dat ssdt10.dat ssdt14.dat -d ssdt8.dat
iasl -e ssdt1.dat ssdt14.dat -d ssdt9.dat
iasl -e ssdt1.dat ssdt14.dat -d ssdt10.dat
iasl -e ssdt1.dat ssdt14.dat -d ssdt11.dat
iasl -e ssdt1.dat ssdt14.dat -d ssdt12.dat
iasl -e ssdt1.dat ssdt8.dat ssdt14.dat -d ssdt13.dat
iasl -e ssdt1.dat ssdt5.dat ssdt6.dat -d ssdt14.dat (broken, no matter what combination I use after -e)
iASL Warning: There were 9 external control methods found during
disassembly, but only 5 were resolved (4 unresolved). Additional
ACPI tables may be required to properly disassemble the code. This
resulting disassembler output file may not compile because the
disassembler did not know how many arguments to assign to the
unresolved methods. Note: SSDTs can be dynamically loaded at
runtime and may or may not be available via the host OS.
RWEverything shows:
Store(_SB.ALIB(Zero, M207), M207)
iasl dsl file shows:
= _SB.ALIB /* External reference */
M207
M207
iasl version, obviously isn't going to work due to missing/misplaced information.
I'll attach my .dat files so you can figure out why disassembly is broken.
These are from an ACER Nitro5 Ryzen 5 model (AN515-42-R5GT)
RWEverything disassembly
RWEverything.tar.gz
iasl disassembly
iasl-DSL.tar.gz
Original ACPIDUMP
bios_sck.tar.gz
Greetings,
We're working on a UB Sanitizer for the NetBSD amd64 kernel.
We've successfully booted the kernel to a shell and we are currently handling UB reports as reported on dmesg.
We have a batch of reports concerning acpica,
they can be seen as follows:
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/namespace/nsaccess.c:601:9, load of misaligned address 0xffffffff82c0554e for type 'const UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/utilities/utstring.c:198:9, load of misaligned address 0xffffffff82c09027 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/tables/tbprint.c:148:9, load of misaligned address 0xffffffff82b08e97 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/tables/tbprint.c:215:9, load of misaligned address 0xffffffff82c07172 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/tables/tbprint.c:216:9, load of misaligned address 0xffffffff82b08e97 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/tables/tbutils.c:398:13, load of misaligned address 0xffffffff82b5bdda for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/tables/tbxfload.c:187:10, load of misaligned address 0xffffffff82b5bddf for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/dispatcher/dsmthdat.c:126:9, load of misaligned address 0xffffffff82c02169 for type 'const UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/parser/psargs.c:457:9, load of misaligned address 0xffff8000439a8071 for type 'const UINT16' which requires 2 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/parser/psargs.c:466:9, load of misaligned address 0xffff8000439a80c1 for type 'const UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/parser/psargs.c:601:9, load of misaligned address 0xffff8000439a8107 for type 'const UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/namespace/nsaccess.c:601:9, load of misaligned address 0xffff8000439a8162 for type 'const UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/dispatcher/dsinit.c:254:9, load of misaligned address 0xffffffff82b5bddf for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/tables/tbxfload.c:248:15, load of misaligned address 0xffffffff82c05bbb for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/tables/tbxface.c:292:14, load of misaligned address 0xffffffff82b5bdda for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/tables/tbxface.c:394:14, load of misaligned address 0xffffffff82b080f1 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/events/evgpeinit.c:362:5, store to misaligned address 0xffffffff855e5a53 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/namespace/nsinit.c:515:10, load of misaligned address 0xffffffff82c05a21 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/events/evregion.c:611:14, load of misaligned address 0xffffffff82be38cb for type 'const ACPI_NAME' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/namespace/nsinit.c:692:10, load of misaligned address 0xffffffff82b5af46 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/utilities/utpredef.c:132:13, load of misaligned address 0xffffffff82af2187 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:188:13, store to misaligned address 0xffffe4007f566c21 for type 'UINT16' which requires 2 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:195:13, load of misaligned address 0xffffe4007f57170e for type 'const UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:195:13, store to misaligned address 0xffffe4007f566ca9 for type 'UINT32' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsaddr.c:331:22, member access within misaligned address 0xffffe4007f571722 for type 'union AML_RESOURCE' which requires 4 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:202:13, load of misaligned address 0xffffe4007f571742 for type 'const UINT64' which requires 8 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:202:13, store to misaligned address 0xffffe4007f566d09 for type 'UINT64' which requires 8 byte alignment
[ 1.0000030] KUBSan: Undefined behavior in /usr/src/sys/dev/acpi/acpica/OsdHardware.c:265:17, left shift of 255 by 24 places cannot be represented in type 'int'
[ 1.0565892] pckbc1 at acpi0 (KBD, PNP0303) (kbd port)KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rscalc.c:520:13, load of misaligned address 0xffffe4007fd870e9 for type 'const UINT16' which requires 2 byte alignment
[ 1.0565892] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsmisc.c:389:13, load of misaligned address 0xffffe4007fd870e9 for type 'const UINT16' which requires 2 byte alignment
[ 1.0565892] piixpm0: KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:299:37, member access within misaligned address 0xffffe4007fbf5719 for type 'union AML_RESOURCE' which requires 4 byte alignment
[ 1.0565892] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:250:25, member access within misaligned address 0xffffe4007fbf5719 for type 'union AML_RESOURCE' which requires 4 byte alignment
[ 1.0565892] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:264:31, member access within misaligned address 0xffffe4007fbf5719 for type 'union AML_RESOURCE' which requires 4 byte alignment
[ 1.0565892] KUBSan: Undefined behavior in /usr/src/sys/external/bsd/acpica/dist/resources/rsutils.c:263:41, member access within misaligned address 0xffffe4007fbf5719 for type 'union AML_RESOURCE' which requires 4 byte alignment
All the reports we're handling are stored on https://netbsd.org/~kamil/kubsan/
We would like to cooperate to resolve these issues.
Hi,
at https://bugs.launchpad.net/ubuntu/+source/acpica-unix/+bug/1483836 it was reported that running the tests on powerpc fails with a slew of segfaults. I've reproduced this with the latest git HEAD, although that was with all the debian patches re-added. Any hints on how to go about figuring out what's going wrong would be greatly appreciated.
We're in the process of updating the ACPICA code, moving from 20160529 to the latest release to fix some deadlock issues and have discovered several systems whose ACPI tables now generate warnings that look like the following:
ACPI Error: Result stack is empty! State=fffffe2528f55e88 (20180629/dswstate-218)
ACPI Error: AE_AML_NO_RETURN_VALUE, Missing or null operand (20180629/dsutils-809)
ACPI Error: AE_AML_NO_RETURN_VALUE, While creating Arg 0 (20180629/dsutils-937)
We've been able to narrow this further down and it appears that all in cases the encoding of OperationRegion is using a Method to calculate the Offset with AML that looks something like the following when decompiled with iasl 20160108-64:
...
Name (PMBV, 0x00)
Method (PMB1, 0, NotSerialized)
{
If ((PMBV == 0x00))
{
PMBV = (\_SB.PC00.PMC1.ACBA << 0x08)
}
Return (PMBV) /* \PMBV */
}
Name (PWRV, 0x00)
Method (PWRM, 0, NotSerialized)
{
If ((PWRV == 0x00))
{
PWRV = (\_SB.PC00.PMC1.PWBA << 0x0C)
}
Return (PWRV) /* \PWRV */
}
OperationRegion (PMIO, SystemIO, PMB1 (), 0x80)
Field (PMIO, ByteAcc, NoLock, Preserve)
{
Offset (0x01),
PBSS, 1,
Offset (0x40),
, 17,
GPEC, 1
}
OperationRegion (PMLP, SystemIO, (PMB1 () + 0x80), 0x20)
Field (PMLP, ByteAcc, NoLock, Preserve)
{
Offset (0x10),
Offset (0x11),
GE08, 1,
, 8,
GE17, 1,
, 17,
GE35, 1,
, 9,
GE45, 1,
Offset (0x16),
GE48, 1,
, 2,
GE51, 1,
Offset (0x20)
}
...
If we look at the stack trace from the kernel where the error occurs we see the following ACPICA functions:
fffffffffbc97a30 acpica`AcpiError+0x1f()
fffffffffbc97ab0 acpica`AcpiDsResultPop+0x15f(fffffffffbc97ae8, fffffe2528f55e88)
fffffffffbc97b40 acpica`AcpiDsCreateOperand+0x92(fffffe2528f55e88, fffffe256185f978, 0)
fffffffffbc97c00 acpica`AcpiDsCreateOperands+0x11e(fffffe2528f55e88, fffffe256185f978)
fffffffffbc97c60 acpica`AcpiDsExecEndOp+0x143(fffffe2528f55e88)
fffffffffbc97ce0 acpica`AcpiPsParseLoop+0x231(fffffe2528f55e88)
fffffffffbc97d60 acpica`AcpiPsParseAml+0x20b(fffffe2528f55e88)
fffffffffbc97db0 acpica`AcpiPsExecuteTable+0x125(fffffe25446cdf88)
fffffffffbc97e40 acpica`AcpiNsExecuteTable+0x170(1, fffffffffc118640)
fffffffffbc97e90 acpica`AcpiNsParseTable+0x65(1, fffffffffc118640)
fffffffffbc97ed0 acpica`AcpiNsLoadTable+0xb2(1, fffffffffc118640)
fffffffffbc97f30 acpica`AcpiTbLoadNamespace+0x112()
fffffffffbc97f50 acpica`AcpiLoadTables+0x3d()
<OS-specific functions follow>
Looking further, if I print out the argument types that we seemed to have parsed and stored in AcpiDsCreateOperands(), the first argument, at index 1 is a byte const value which represents the Length. If we print the ACPI_PARSE_OBJECT structure for that, we see:
[0]> 0xfffffe256185f900::print ACPI_PARSE_OBJECT
{
Common = {
Parent = 0xfffffe25615ef788
DescriptorType = 0xd
Flags = 0x1
AmlOpcode = 0xa
Aml = 0xfffffe226ce44548
Next = 0
Node = 0
Value = {
Integer = 0x20
Size = 0x20
String = 0x20
Buffer = 0x20
Name = 0x20
Arg = 0x20
Tag = {
BitOffset = 0x20
BitLength = 0
}
}
ArgListLength = 0
DisasmFlags = 0
DisasmOpcode = 0
OperatorSymbol = 0
AmlOpName = [ "ByteConst" ]
}
Named = {
Parent = 0xfffffe25615ef788
DescriptorType = 0xd
Flags = 0x1
AmlOpcode = 0xa
Aml = 0xfffffe226ce44548
Next = 0
Node = 0
Value = {
Integer = 0x20
Size = 0x20
String = 0x20
Buffer = 0x20
Name = 0x20
Arg = 0x20
Tag = {
BitOffset = 0x20
BitLength = 0
}
}
ArgListLength = 0
DisasmFlags = 0
DisasmOpcode = 0
OperatorSymbol = 0
AmlOpName = [ "ByteConst" ]
Path = 0xbaddcafebaddcabb
Data = 0x5649feedface
Length = 0x61876988
Name = 0xfffffe25
}
Asl = {
Parent = 0xfffffe25615ef788
DescriptorType = 0xd
Flags = 0x1
AmlOpcode = 0xa
Aml = 0xfffffe226ce44548
Next = 0
Node = 0
Value = {
Integer = 0x20
Size = 0x20
String = 0x20
Buffer = 0x20
Name = 0x20
Arg = 0x20
Tag = {
BitOffset = 0x20
BitLength = 0
}
}
ArgListLength = 0
DisasmFlags = 0
DisasmOpcode = 0
OperatorSymbol = 0
AmlOpName = [ "ByteConst" ]
Child = 0xbaddcafebaddcabb
ParentMethod = 0x5649feedface
Filename = 0xfffffe2561876988
FileChanged = 0x65
ParentFilename = 0x58
ExternalName = 0xfffffe256185f450
Namepath = 0xcacacacacacaca01
NameSeg = [ '\312', '\312', '\312', '\312' ]
ExtraValue = 0xcacacaca
Column = 0xcacacaca
LineNumber = 0xcacacaca
LogicalLineNumber = 0xcacacaca
LogicalByteOffset = 0xcacacaca
EndLine = 0xcacacaca
EndLogicalLine = 0xcacacaca
AcpiBtype = 0xcacacaca
AmlLength = 0xcacacaca
AmlSubtreeLength = 0xcacacaca
FinalAmlLength = 0xcacacaca
FinalAmlOffset = 0xcacacaca
CompileFlags = 0xcacacaca
ParseOpcode = 0xcaca
AmlOpcodeLength = 0xca
AmlPkgLenBytes = 0xca
Extra = 0xca
ParseOpName = [ '\312', '\312', '\312', '\273', '\312', '\335', '\272', '\376', '\312', '\335', '\272', '\316', '\372', '\355', '\376', 'I', 'V', '\0', '\0', '\260' ]
}
}
However, when we look at the index zero entry, it appears to strictly be an AML return type:
[0]> <rsi::print ACPI_PARSE_OBJECT
{
Common = {
Parent = 0xfffffe25615ef788
DescriptorType = 0xd
Flags = 0x1
AmlOpcode = 0x36
Aml = 0xfffffe226ce44540
Next = 0xfffffe256185f900
Node = 0
Value = {
Integer = 0
Size = 0
String = 0
Buffer = 0
Name = 0
Arg = 0
Tag = {
BitOffset = 0
BitLength = 0
}
}
ArgListLength = 0
DisasmFlags = 0
DisasmOpcode = 0
OperatorSymbol = 0
AmlOpName = [ "-Return Value-" ]
}
Named = {
Parent = 0xfffffe25615ef788
DescriptorType = 0xd
Flags = 0x1
AmlOpcode = 0x36
Aml = 0xfffffe226ce44540
Next = 0xfffffe256185f900
Node = 0
Value = {
Integer = 0
Size = 0
String = 0
Buffer = 0
Name = 0
Arg = 0
Tag = {
BitOffset = 0
BitLength = 0
}
}
ArgListLength = 0
DisasmFlags = 0
DisasmOpcode = 0
OperatorSymbol = 0
AmlOpName = [ "-Return Value-" ]
Path = 0xbaddcafebaddcabb
Data = 0x5649feedface
Length = 0x44745ce8
Name = 0xfffffe25
}
Asl = {
Parent = 0xfffffe25615ef788
DescriptorType = 0xd
Flags = 0x1
AmlOpcode = 0x36
Aml = 0xfffffe226ce44540
Next = 0xfffffe256185f900
Node = 0
Value = {
Integer = 0
Size = 0
String = 0
Buffer = 0
Name = 0
Arg = 0
Tag = {
BitOffset = 0
BitLength = 0
}
}
ArgListLength = 0
DisasmFlags = 0
DisasmOpcode = 0
OperatorSymbol = 0
AmlOpName = [ "-Return Value-" ]
Child = 0xbaddcafebaddcabb
ParentMethod = 0x5649feedface
Filename = 0xfffffe2544745ce8 ""
FileChanged = 0x5
ParentFilename = 0x58
ExternalName = 0xfffffe25446cd718
Namepath = 0xcacacacacacaca01
NameSeg = [ '\312', '\312', '\312', '\312' ]
ExtraValue = 0xcacacaca
Column = 0xcacacaca
LineNumber = 0xcacacaca
LogicalLineNumber = 0xcacacaca
LogicalByteOffset = 0xcacacaca
EndLine = 0xcacacaca
EndLogicalLine = 0xcacacaca
AcpiBtype = 0xcacacaca
AmlLength = 0xcacacaca
AmlSubtreeLength = 0xcacacaca
FinalAmlLength = 0xcacacaca
FinalAmlOffset = 0xcacacaca
CompileFlags = 0xcacacaca
ParseOpcode = 0xcaca
AmlOpcodeLength = 0xca
AmlPkgLenBytes = 0xca
Extra = 0xca
ParseOpName = [ '\312', '\312', '\312', '\273', '\312', '\335', '\272', '\376', '\312', '\335', '\272', '\316', '\372', '\355', '\376', 'I', 'V', '\0', '\0', '\020' ]
}
}
When we double check the next pointer, it does seem to point to the right entry point. I suspect that what's happening here is that for some reason we're not getting the full method translation into the arguments structure and only the return of the method. Beacuse the only other argument is the constant argument indicating the length to the create region, it would make sense that an operand pop would fail.
Looking at the change log, there doesn't appear to be anything obvious that would correspond go this change in behavior; however, I could have easily overlooked something. Was there a change in recent ACPI code that would have led to this processing being problematic or perhaps is it exposing an issue in some tables from vendors that we're testing against? If it helps to look at intermediate releases, I can try and take a look.
Found via valgrind. The actual violation takes place on line 281, where it checks for a double quote character. The problem is that if String is zero length, then End gets set to 1 byte before Start (line 248).
diff --git a/source/compiler/dtio.c b/source/compiler/dtio.c
index 0ba15b4..cfbd0d0 100644
--- a/source/compiler/dtio.c
+++ b/source/compiler/dtio.c
@@ -236,7 +236,7 @@ DtTrim (
/* Skip lines that start with a space */
- if (!strcmp (String, " "))
+ if (!strcmp (String, " ") || strlen(String) < 1)
{
ReturnString = UtLocalCacheCalloc (1);
return (ReturnString);It is bogus in C to subtract arbitrary pointers that do not point to the same object (or one beyond the end of the object), and the use of difference for these is not needed. (C11 §6.5.6, constraint 9, p.93 of the last draft.)
C defines offsetof() in stddef.h since C89, but even if we are concerned about running on environments that do not support offsetof, it would be more correct to just cast the corresponding pointers to uintptr_t and skip the subtraction. NULL == 0, regardless of bit representation.
I suggest (something along the lines of):
#define ACPI_TO_INTEGER(p) ((uintptr_t)(p))
#define ACPI_OFFSET(d, f) (offsetof(d, f))
I got TPM2 ACPI table binary from /sys/firmware/acpi/tables/TPM2. Then I use iasl -d TPM2 to get disassemble file TPM2.dsl.
But when I want to compile TPM2.dsl, there comes out an error "Error 6126 - Could not compile input file".
DSL content:
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20180629 (64-bit version)
* Copyright (c) 2000 - 2018 Intel Corporation
*
* Disassembly of TPM2, Wed Aug 8 08:25:35 2018
*
* ACPI Data Table [TPM2]
*
* Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue
*/
[000h 0000 4] Signature : "TPM2" [Trusted Platform Module hardware interface table]
[004h 0004 4] Table Length : 00000034
[008h 0008 1] Revision : 03
[009h 0009 1] Checksum : 8D
[00Ah 0010 6] Oem ID : ""
[010h 0016 8] Oem Table ID : ""
[018h 0024 4] Oem Revision : 00000000
[01Ch 0028 4] Asl Compiler ID : ""
[020h 0032 4] Asl Compiler Revision : 00000000
[024h 0036 2] Platform Class : 0000
[026h 0038 2] Reserved : 0000
[028h 0040 8] Control Address : 00000000FED40040
[030h 0048 4] Start Method : 07 [Command Response Buffer]
/**** ACPI table terminates in the middle of a data structure! (dump table) */
Raw Table Data: Length 52 (0x34)
0000: 54 50 4D 32 34 00 00 00 03 8D 00 00 00 00 00 00 // TPM24...........
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // ................
0020: 00 00 00 00 00 00 00 00 40 00 D4 FE 00 00 00 00 // ........@.......
0030: 07 00 00 00 // ....
The original TPM2 binary: TPM2_orig.zip
The disassemble DSL file: TPM2_dsl.zip
For example, you can create a template IORT table on Linux with:
$ iasl -T IORT
Then, convert it to DOS format:
$ unix2dos iort.asl
When you try to recompile it, you get:
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20181003
Copyright (c) 2000 - 2018 Intel Corporation
iort.asl 55: [0084] Padding : \
Error 6300 - Invalid element in buffer initializer list ^ (\)
Table Input: iort.asl - 179 lines, 8287 bytes, 146 fields
If you remove the '', this compiles fine. Or, if the file is in Unix format, it compiles without changing anything.
This has apparently been true for several releases but is definitely in the current code.
uname -a
Linux homeplanet 3.11.3-1-ARCH #1 SMP PREEMPT Wed Oct 2 01:38:48 CEST 2013 x86_64 GNU/Linux
/usr/include/features.h:327:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] # warning _FORTIFY_SOURCE requires compiling with optimization (-O) ^ cc1: all warnings being treated as errors
The following code in ./generate/unix/iasl/Makefile doesn’t work if the absolute path contains a " " (Space), e.g. /Volumes/Macintosh SR0/...
Possible fix: don't use absolute paths.
safe_yacc = \
_d=`mktemp -d $(OBJDIR)/$(1).XXXXXX` &&\
cd $$_d &&\
$(YACC) $(YFLAGS) -v -d -p$(1) $(abspath $(2)) &&\
cd - > /dev/null;\
mv $$_d/y.tab$(suffix $(3)) $(3);\
_r=$$?;\
rm -fr $$_d;\
exit $$_r
######### Output of make (shortened) ########
$ pwd
/Users/mklengel/Development/Repositories/acpica
$ make
... (irrelevant lines removed)
obj/acpixtract ../../../source/tools/acpixtract/acpixtract.c
obj/acpixtract ../../../source/tools/acpixtract/axmain.c
obj/acpixtract ../../../source/tools/acpixtract/axutils.c
obj/acpixtract ../../../source/common/getopt.c
obj/acpixtract ../../../source/os_specific/service_layers/osunixxf.c
obj/acpixtract ../../../source/components/utilities/utascii.c
obj/acpixtract ../../../source/components/utilities/utdebug.c
obj/acpixtract ../../../source/components/utilities/utexcep.c
obj/acpixtract ../../../source/components/utilities/utglobal.c
obj/acpixtract ../../../source/components/utilities/uthex.c
obj/acpixtract ../../../source/components/utilities/utmath.c
obj/acpixtract ../../../source/components/utilities/utnonansi.c
obj/acpixtract ../../../source/components/utilities/utxferror.c
- Link obj/acpixtract
- Copy obj/acpixtract to ../bin/acpixtract
- m4 Preprocess main iASL parser
- bison obj/aslcompiler.y
bison: extra operand ‘SR0/Users/mklengel/Development/Repositories/acpica/generate/unix/iasl/obj/aslcompiler.y’
Try 'bison --help' for more information.
mv: rename obj/AslCompiler.xgW7G5/y.tab.h to obj/aslcompiler.y.h: No such file or directory
make[1]: *** [obj/aslcompiler.y.h] Error 1
make: *** [iasl] Error 2
$ find . -type f -exec grep abspath {} \; -print
$(YACC) $(YFLAGS) -v -d -p$(1) $(abspath $(2)) &&\
./generate/unix/iasl/Makefile
Hi, you need to change termio.h to termios.h for OS X
I know there exists at least a man page for acpidump, "COPYRIGHT (c) 2013, Intel Corporation." which is included with the Linux kernel source for a similar version of acpidump. This man page in particular, and the man pages for all the other acpica binaries, seem to be missing from this source.
Do these other man pages exist somewhere?
Would you please include at least the acpidump man page here?
Would you please provide man pages for the other binaries?
The following commit breaks entire ACPICA release process:
ba60e45
It seems it breaks ACPICA release automaton because it breaks acpisrc.
You can confirm the breakage by running:
# generate/linux/gen-patch.sh ba60e45
Please revert it ASAP.
This is a quick note before I go... maybe it helps...
This method is from an Intel DH67GD board...
Method (OSFL, 0, NotSerialized)
{
If (LNotEqual (OSVR, Ones))
{
Return (OSVR)
}
If (LEqual (PICM, Zero))
{
Store (0xAC, DBG8)
}
Store (One, OSVR)
// PROBLEM HERE:
If (CondRefOf (_OSI (Local0), If (_OSI ("Linux"))
{
Store (0x03, OSVR)
}))
{
If (_OSI ("Windows 2001"))
{
Store (0x04, OSVR)
}
If (_OSI ("Windows 2001.1"))
{
Store (0x05, OSVR)
}
If (_OSI ("FreeBSD"))
{
Store (0x06, OSVR)
}
If (_OSI ("HP-UX"))
{
Store (0x07, OSVR)
}
If (_OSI ("OpenVMS"))
{
Store (0x08, OSVR)
}
If (_OSI ("Windows 2001 SP1"))
{
Store (0x09, OSVR)
}
If (_OSI ("Windows 2001 SP2"))
{
Store (0x0A, OSVR)
}
If (_OSI ("Windows 2001 SP3"))
{
Store (0x0B, OSVR)
}
If (_OSI ("Windows 2006"))
{
Store (0x0C, OSVR)
}
If (_OSI ("Windows 2006 SP1"))
{
Store (0x0D, OSVR)
}
If (_OSI ("Windows 2009"))
{
Store (0x0E, OSVR)
}
}
ElseIf (MCTH (_OS, "Microsoft Windows NT"))
{
Store (Zero, OSVR)
}
Return (OSVR)
}
Correct disassembly:
Method (OSFL, 0, NotSerialized)
{
If (LNotEqual (OSVR, Ones))
{
Return (OSVR)
}
If (LEqual (PICM, Zero))
{
Store (0xAC, DBG8)
}
Store (One, OSVR)
If (CondRefOf (_OSI, Local0))
{
If (_OSI ("Linux"))
{
Store (0x03, OSVR)
}
If (_OSI ("Windows 2001"))
{
Store (0x04, OSVR)
}
If (_OSI ("Windows 2001.1"))
{
Store (0x05, OSVR)
}
If (_OSI ("FreeBSD"))
{
Store (0x06, OSVR)
}
If (_OSI ("HP-UX"))
{
Store (0x07, OSVR)
}
If (_OSI ("OpenVMS"))
{
Store (0x08, OSVR)
}
If (_OSI ("Windows 2001 SP1"))
{
Store (0x09, OSVR)
}
If (_OSI ("Windows 2001 SP2"))
{
Store (0x0A, OSVR)
}
If (_OSI ("Windows 2001 SP3"))
{
Store (0x0B, OSVR)
}
If (_OSI ("Windows 2006"))
{
Store (0x0C, OSVR)
}
If (_OSI ("Windows 2006 SP1"))
{
Store (0x0D, OSVR)
}
If (_OSI ("Windows 2009"))
{
Store (0x0E, OSVR)
}
}
Else
{
If (MCTH (_OS, "Microsoft Windows NT"))
{
Store (Zero, OSVR)
}
If (MCTH (_OS, "Microsoft Windows"))
{
Store (One, OSVR)
}
If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition"))
{
Store (0x02, OSVR)
}
If (MCTH (_OS, "Linux"))
{
Store (0x03, OSVR)
}
If (MCTH (_OS, "FreeBSD"))
{
Store (0x06, OSVR)
}
If (MCTH (_OS, "HP-UX"))
{
Store (0x07, OSVR)
}
If (MCTH (_OS, "OpenVMS"))
{
Store (0x08, OSVR)
}
}
Return (OSVR)
}
../../../source/os_specific/service_layers/osunixxf.c:832:42: error: 'tmpnam' is
deprecated: This function is provided for compatibility reasons only. Due
to security concerns inherent in the design of tmpnam(3), it is highly
recommended that you use mkstemp(3) instead.
[-Werror,-Wdeprecated-declarations]
char *SemaphoreName = tmpnam (NULL);
^
/usr/include/stdio.h:276:7: note: 'tmpnam' has been explicitly marked deprecated
here
char *tmpnam(char *);
^
../../../source/os_specific/service_layers/osunixxf.c:885:9: error: 'sem_close'
is deprecated [-Werror,-Wdeprecated-declarations]
if (sem_destroy (Sem) == -1)
^
../../../source/include/platform/acmacosx.h:122:29: note: expanded from macro
'sem_destroy'
^
/usr/include/sys/semaphore.h:53:5: note: 'sem_close' has been explicitly marked
deprecated here
int sem_destroy(sem_t *) __deprecated;
^
../../../source/include/platform/acmacosx.h:122:29: note: expanded from macro
'sem_destroy'
^
2 errors generated.
make[1]: *** [obj/osunixxf.o] Error 1
make: *** [acpiexec] Error 2
Hello,
The latest iasl fails to decode a genuine RSDP table found in a Lenovo laptop. Older iasl versions seem to have no issues with this file. The returned error for running iasl -d RSDP.aml is as follows:
Could not get ACPI tables from RSDP.aml, AE_BAD_SIGNATURE
Here are the compiled and decompiled table (with a previous version of iasl): RSDP.zip
Thanks
Compilation failing under gcc8 (NixOS, gcc 8.1.0, Linux 4.14.39).
Error message:
obj/iasl ../../../source/compiler/aslanalyze.c
../../../source/compiler/aslanalyze.c: In function 'AnCheckMethodReturnValue':
../../../source/compiler/aslanalyze.c:467:17: error: '%s' directive writing up to 32767 bytes into a region of size 32752 [-Werror=format-overflow=]
"Method returns [%s], %s operator requires [%s]",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
StringBuffer, OpInfo->Name, StringBuffer2);
~~~~~~~~~~~~
In file included from /nix/store/lb3kkvyylnbcxn5jad9i11szxlhkpkjq-glibc-2.27-dev/include/stdio.h:862,
from ../../../source/include/platform/acenv.h:479,
from ../../../source/include/acpi.h:164,
from ../../../source/compiler/aslcompiler.h:155,
from ../../../source/compiler/aslanalyze.c:152:
/nix/store/lb3kkvyylnbcxn5jad9i11szxlhkpkjq-glibc-2.27-dev/include/bits/stdio2.h:33:10: note: '__builtin___sprintf_chk' output 41 or more bytes (assuming 65575) into a destination of size 32768
return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
See also:
Hi
I'm trying to fix Undefined Behaviour reports by UBSan in NetBSD. I have built with the ACPI_MISALIGNMENT_NOT_SUPPORTED macro, this has taken care of most of the reports but a few still remain.
Can these be fixed?
UBSan: Undefined Behavior in components/events/evregion.c:719:14, load of misaligned address 0xffffffff82e27b5b for type 'const ACPI_NAME' which requires 4 byte alignment
UBSan: Undefined Behavior in components/resources/rsaddr.c:439:22, member access within misaligned address 0xffff922460d45f62 for type 'union AML_RESOURCE' which requires 4 byte alignment
UBSan: Undefined Behavior in components/resources/rsutils.c:407:37, member access within misaligned address 0xffff922460d76419 for type 'union AML_RESOURCE' which requires 4 byte alignment
UBSan: Undefined Behavior in components/resources/rsutils.c:358:25, member access within misaligned address 0xffff922460d76419 for type 'union AML_RESOURCE' which requires 4 byte alignment
UBSan: Undefined Behavior in components/resources/rsutils.c:372:31, member access within misaligned address 0xffff922460d76419 for type 'union AML_RESOURCE' which requires 4 byte alignment
UBSan: Undefined Behavior in components/resources/rsutils.c:371:41, member access within misaligned address 0xffff922460d76419 for type 'union AML_RESOURCE' which requires 4 byte alignment
PaddingLength is never initialized in DtCompileIort(), but the value is dereferenced in DtCompileGeneric() before it is ever assigned there (in the conditional):
if (Length && *Length)
{
*Length = 0;
}
Zero initializing it in either the caller or callee seems to match intent and would remove the UB.
E.g., in DtCompileGeneric this code has the same behavior without the UB:
if (Length)
*Length = 0;
This code, formerly valid, now yields an error:
DefinitionBlock ("TEST.aml", "DSDT", 2, "FU", "BAR", 0x00000001)
{
Device(BLAH)
{
Method(X, 0, NotSerialized)
{
Notify(^, 0)
}
}
}
Expect: New features don't break existing code.
Many people reported FreeBSD is broken after I merged ACPICA 20170929, e.g.,
https://lists.freebsd.org/pipermail/svn-src-head/2017-September/104683.html
I had no choice but to revert the commit back to 20170831. Now I found the culprit was this commit:
We cannot call AcpiLoadTables() earlier than OS clock/timer initialization because of this commit. Was this commit really necessary? Can't you just add short AcpiOsSleep() for each iteration if you're worried that While() loop ends too quickly?
Source code is
for (i = 0; Args[i].Name && (i < PR_MAX_MACRO_ARGS); i++)
Suggest sanity check array index before use, not after.
I can't compile FACP.dsl (a decompiled FADT table from my BIOS) with iasl, and the message is extraordinarily unhelpful:
$ iasl FACP.dsl
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20180105
Copyright (c) 2000 - 2018 Intel Corporation
Error 6126 - Could not compile input file
Table Input: FACP.dsl - 164 lines, 9229 bytes, 136 fields
Compilation complete. 1 Errors, 0 Warnings, 0 Remarks
I used GDB to figure out where it was breaking, and I ended up doing the following patch to make it work. The output looks fine, but I'm not sure why the change is necessary to begin with.
diff --git a/source/compiler/dtcompile.c b/source/compiler/dtcompile.c
index a850993..52f4302 100644
--- a/source/compiler/dtcompile.c
+++ b/source/compiler/dtcompile.c
@@ -479,7 +479,7 @@ DtCompileDataTable (
/* Complex table, has a handler */
Status = TableData->CmTableHandler ((void **) FieldList);
- if (ACPI_FAILURE (Status))
+ if (ACPI_FAILURE (Status) && Status != AE_END_OF_TABLE)
{
return (Status);
}I'm trying to build Visual Studio solution in Visual Studio 2015. Currently I'm facing lots of build error and warnings.
I've attached migration report generated by Visual Studio 2015 when opening 2008 solution file in 2015.
Any pointers for lead is helpful to proceed further.
Visual_2015_UpgradeLog.zip
Below is the snapshot of error,
Below is the snapshot of warnings,
Note:
This Stdlib.h is access from below path,
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt
[Symptom]:
I ported acpidump to UEFI Shell environment. When dumping special tables like RSDP, RSDT, XSDT, DSDT, FACS, acpidump.efi will generate too many files until it reaches AP_MAX_ACPI_FILES = 256.
This issue doesn't happen with normal tables like BERT, HEST. And doens't happen when dump table by index.
[Root cause]:
These special tables are all singleton. But there's no necessary detection when dump them with instance number > 1.
I utterly see iasl is meant to be an high quality aml compiler fully complaint with latest ACPI spec, but this would help immensely when it comes to fixing bad DSDT tables.
In particular the code I had my hands on at the moment was:
Device (SATA)
{
Name (_ADR, 0x00110000) // _ADR: Address
If ((STCL == 0x0101))
{
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
}....
Fairly, I'm alerted there's an unexpected PARSEOP_IF.. It's an opcode outside of a method after all.
But for as much as I racked my brain I couldn't come up with a rationale of what ever this had been supposed to serve (nor why none of my storage devices hadn't already mishbehaved). I mean, I can't see a way any person, even drunk, could have put something that blatantly amiss there.
Then I found 80d7951, 66e20c8 and so on (btw, thanks for fixing that pesky AE_NOT_FOUND problem).
For as much that code was now illegal, it may still have had its sense once upon a time (and in Windows..)
And I (with no damn docs or datasheet) wouldn't really be able to imagine a consistent substitute, if even possible at all.
So I hoped some kind of "unwarranted within ACPI specs but valid within ACPI Component Architecture" swtich could be added to the project own compiler.
Thanks for your time.
EDIT: Wtf? Is module-level executable code now legitly allowed?
On Haiku ACPI_SEMAPHORE is sem_id (32 bit int).
Setting them to NULL causes
warning: assignment makes integer from pointer without a cast
Is there any simple way to fix it worth the small benefit of building on Haiku without warnings?
Casting NULL to ACPI_SEMAPHORE creates a warning for losing precision (64 to 32 bit).
Log:
.../acpica/components/utilities/utdelete.c: In function 'AcpiUtDeleteInternalObj':
.../acpica/components/utilities/utdelete.c:260:41: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
AcpiGbl_GlobalLockSemaphore = NULL;
^
.../acpica/components/utilities/utdelete.c:279:35: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
Object->Event.OsSemaphore = NULL;
^
.../acpica/components/utilities/utinit.c: In function 'AcpiUtInitGlobals':
.../acpica/components/utilities/utinit.c:283:41: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
AcpiGbl_GlobalLockSemaphore = NULL;
As of:
cd816f3 Merge pull request #255 from zetalog/acpica-1703
Running make on a pristine clone results in the following build error:
make[1]: Entering directory '/home/joe/src/acpica/generate/unix/acpibin'
obj/acpibin ../../../source/tools/acpibin/abcompare.c
obj/acpibin ../../../source/tools/acpibin/abmain.c
obj/acpibin ../../../source/common/cmfsize.c
obj/acpibin ../../../source/common/getopt.c
obj/acpibin ../../../source/components/utilities/utalloc.c
obj/acpibin ../../../source/components/utilities/utascii.c
obj/acpibin ../../../source/components/utilities/utbuffer.c
obj/acpibin ../../../source/components/utilities/utcache.c
obj/acpibin ../../../source/components/utilities/utdebug.c
obj/acpibin ../../../source/components/utilities/utdecode.c
obj/acpibin ../../../source/components/utilities/utexcep.c
obj/acpibin ../../../source/components/utilities/utglobal.c
obj/acpibin ../../../source/components/utilities/utlock.c
obj/acpibin ../../../source/components/utilities/utmath.c
obj/acpibin ../../../source/components/utilities/utmisc.c
obj/acpibin ../../../source/components/utilities/utmutex.c
In file included from ../../../source/include/acpi.h:169:0,
from ../../../source/components/utilities/utmutex.c:152:
../../../source/components/utilities/utmutex.c: In function ‘AcpiUtAcquireMutex’:
../../../source/components/utilities/utmutex.c:436:36: error: implicit declaration of function ‘AcpiUtGetMutexName’ [-Werror=implicit-function-declaration]
(UINT32) ThisThreadId, AcpiUtGetMutexName (MutexId)));
^
../../../source/include/acoutput.h:343:55: note: in definition of macro ‘ACPI_EXCEPTION’
#define ACPI_EXCEPTION(plist) AcpiException plist
^~~~~
../../../source/components/utilities/utmutex.c:434:9: error: nested extern declaration of ‘AcpiUtGetMutexName’ [-Werror=nested-externs]
ACPI_EXCEPTION ((AE_INFO, Status,
^~~~~~~~~~~~~~
In file included from ../../../source/include/acpi.h:169:0,
from ../../../source/components/utilities/utmutex.c:152:
../../../source/components/utilities/utmutex.c:435:13: error: format ‘%s’ expects argument of type ‘char *’, but argument 6 has type ‘int’ [-Werror=format=]
"Thread %u could not acquire Mutex [%s]",
^
../../../source/include/acoutput.h:343:55: note: in definition of macro ‘ACPI_EXCEPTION’
#define ACPI_EXCEPTION(plist) AcpiException plist
^~~~~
../../../source/components/utilities/utmutex.c: In function ‘AcpiUtReleaseMutex’:
../../../source/components/utilities/utmutex.c:476:13: error: format ‘%s’ expects argument of type ‘char *’, but argument 4 has type ‘int’ [-Werror=format=]
"Mutex [%s] is not acquired, cannot release",
^
../../../source/include/acoutput.h:344:51: note: in definition of macro ‘ACPI_ERROR’
#define ACPI_ERROR(plist) AcpiError plist
^~~~~
cc1: all warnings being treated as errors
make[1]: *** [../Makefile.rules:20: obj/utmutex.o] Error 1
make[1]: Leaving directory '/home/joe/src/acpica/generate/unix/acpibin'
make: *** [generate/unix/Makefile.common:7: acpibin] Error 2
OS: latest Arch Linux for x86_64
Compiler: gcc (GCC) 6.3.1 20170306
Also seen on an Ubuntu 17.04 pbuilder chroot, gcc at package version 4:6.3.0-2ubuntu1
Hi,
My environment:
When I disassembled some of the Qemu's ACPI tables like APIC or HPET using:
iasl -e DSDT -e SSDT -d HPET
I almost always received:
*** Error in /usr/bin/iasl': double free or corruption (!prev): 0x0881bc98 *** ======= Backtrace: ========= /lib/libc.so.6[0x46205d12] /usr/bin/iasl[0x80a5a66] /usr/bin/iasl[0x80a2717] /usr/bin/iasl[0x80a284b] /usr/bin/iasl[0x805bf32] /usr/bin/iasl[0x8072352] /usr/bin/iasl[0x80726c1] /usr/bin/iasl[0x80725f5] /usr/bin/iasl[0x80491a9] /lib/libc.so.6(__libc_start_main+0xf3)[0x461a9963] /usr/bin/iasl[0x80491fd] ======= Memory map: ======== 08047000-0810d000 r-xp 00000000 08:06 48242 /usr/bin/iasl 0810d000-0810e000 r--p 000c5000 08:06 48242 /usr/bin/iasl 0810e000-0810f000 rw-p 000c6000 08:06 48242 /usr/bin/iasl 0810f000-08113000 rw-p 00000000 00:00 0 087f7000-08839000 rw-p 00000000 00:00 0 [heap] 4616d000-4618c000 r-xp 00000000 08:06 4415 /usr/lib/ld-2.17.so 4618c000-4618d000 r--p 0001e000 08:06 4415 /usr/lib/ld-2.17.so 4618d000-4618e000 rw-p 0001f000 08:06 4415 /usr/lib/ld-2.17.so 46190000-46348000 r-xp 00000000 08:06 4643 /usr/lib/libc-2.17.so 46348000-46349000 ---p 001b8000 08:06 4643 /usr/lib/libc-2.17.so 46349000-4634b000 r--p 001b8000 08:06 4643 /usr/lib/libc-2.17.so 4634b000-4634c000 rw-p 001ba000 08:06 4643 /usr/lib/libc-2.17.so 4634c000-4634f000 rw-p 00000000 00:00 0 463d2000-463ed000 r-xp 00000000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 463ed000-463ee000 r--p 0001a000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 463ee000-463ef000 rw-p 0001b000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 b7741000-b7742000 rw-p 00000000 00:00 0 b776c000-b776f000 rw-p 00000000 00:00 0 b776f000-b7770000 r-xp 00000000 00:00 0 [vdso] bfc6f000-bfc91000 rw-p 00000000 00:00 0 [stack] *** Error in/usr/bin/iasl': double free or corruption (!prev): 0x09286cd8 ***
======= Backtrace: =========
/lib/libc.so.6[0x46205d12]
/usr/bin/iasl[0x80a5a66]
/usr/bin/iasl[0x80a2717]
/usr/bin/iasl[0x80a284b]
/usr/bin/iasl[0x805bf32]
/usr/bin/iasl[0x8072352]
/usr/bin/iasl[0x80726c1]
/usr/bin/iasl[0x80725f5]
/usr/bin/iasl[0x80491a9]
/lib/libc.so.6(__libc_start_main+0xf3)[0x461a9963]
/usr/bin/iasl[0x80491fd]
======= Memory map: ========
08047000-0810d000 r-xp 00000000 08:06 48242 /usr/bin/iasl
0810d000-0810e000 r--p 000c5000 08:06 48242 /usr/bin/iasl
0810e000-0810f000 rw-p 000c6000 08:06 48242 /usr/bin/iasl
0810f000-08113000 rw-p 00000000 00:00 0
09262000-092a4000 rw-p 00000000 00:00 0 [heap]
4616d000-4618c000 r-xp 00000000 08:06 4415 /usr/lib/ld-2.17.so
4618c000-4618d000 r--p 0001e000 08:06 4415 /usr/lib/ld-2.17.so
4618d000-4618e000 rw-p 0001f000 08:06 4415 /usr/lib/ld-2.17.so
46190000-46348000 r-xp 00000000 08:06 4643 /usr/lib/libc-2.17.so
46348000-46349000 ---p 001b8000 08:06 4643 /usr/lib/libc-2.17.so
46349000-4634b000 r--p 001b8000 08:06 4643 /usr/lib/libc-2.17.so
4634b000-4634c000 rw-p 001ba000 08:06 4643 /usr/lib/libc-2.17.so
4634c000-4634f000 rw-p 00000000 00:00 0
463d2000-463ed000 r-xp 00000000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1
463ed000-463ee000 r--p 0001a000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1
463ee000-463ef000 rw-p 0001b000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1
b774b000-b774c000 rw-p 00000000 00:00 0
b7776000-b7779000 rw-p 00000000 00:00 0
b7779000-b777a000 r-xp 00000000 00:00 0 [vdso]
bfd37000-bfd59000 rw-p 00000000 00:00 0 [stack]
*** Error in /usr/bin/iasl': double free or corruption (!prev): 0x09587c58 *** ======= Backtrace: ========= /lib/libc.so.6[0x46205d12] /usr/bin/iasl[0x80a5a66] /usr/bin/iasl[0x80a2717] /usr/bin/iasl[0x80a284b] /usr/bin/iasl[0x805bf32] /usr/bin/iasl[0x8072352] /usr/bin/iasl[0x80726c1] /usr/bin/iasl[0x80725f5] /usr/bin/iasl[0x80491a9] /lib/libc.so.6(__libc_start_main+0xf3)[0x461a9963] /usr/bin/iasl[0x80491fd] ======= Memory map: ======== 08047000-0810d000 r-xp 00000000 08:06 48242 /usr/bin/iasl 0810d000-0810e000 r--p 000c5000 08:06 48242 /usr/bin/iasl 0810e000-0810f000 rw-p 000c6000 08:06 48242 /usr/bin/iasl 0810f000-08113000 rw-p 00000000 00:00 0 09563000-095a5000 rw-p 00000000 00:00 0 [heap] 4616d000-4618c000 r-xp 00000000 08:06 4415 /usr/lib/ld-2.17.so 4618c000-4618d000 r--p 0001e000 08:06 4415 /usr/lib/ld-2.17.so 4618d000-4618e000 rw-p 0001f000 08:06 4415 /usr/lib/ld-2.17.so 46190000-46348000 r-xp 00000000 08:06 4643 /usr/lib/libc-2.17.so 46348000-46349000 ---p 001b8000 08:06 4643 /usr/lib/libc-2.17.so 46349000-4634b000 r--p 001b8000 08:06 4643 /usr/lib/libc-2.17.so 4634b000-4634c000 rw-p 001ba000 08:06 4643 /usr/lib/libc-2.17.so 4634c000-4634f000 rw-p 00000000 00:00 0 463d2000-463ed000 r-xp 00000000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 463ed000-463ee000 r--p 0001a000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 463ee000-463ef000 rw-p 0001b000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 b77af000-b77b0000 rw-p 00000000 00:00 0 b77da000-b77dd000 rw-p 00000000 00:00 0 b77dd000-b77de000 r-xp 00000000 00:00 0 [vdso] bfe96000-bfeb8000 rw-p 00000000 00:00 0 [stack] *** Error in/usr/bin/iasl': double free or corruption (!prev): 0x096c7c98 ***
======= Backtrace: =========
/lib/libc.so.6[0x46205d12]
/usr/bin/iasl[0x80a5a66]
/usr/bin/iasl[0x80a2717]
/usr/bin/iasl[0x80a284b]
/usr/bin/iasl[0x805bf32]
/usr/bin/iasl[0x8072352]
/usr/bin/iasl[0x80726c1]
/usr/bin/iasl[0x80725f5]
/usr/bin/iasl[0x80491a9]
/lib/libc.so.6(__libc_start_main+0xf3)[0x461a9963]
/usr/bin/iasl[0x80491fd]
======= Memory map: ========
08047000-0810d000 r-xp 00000000 08:06 48242 /usr/bin/iasl
0810d000-0810e000 r--p 000c5000 08:06 48242 /usr/bin/iasl
0810e000-0810f000 rw-p 000c6000 08:06 48242 /usr/bin/iasl
0810f000-08113000 rw-p 00000000 00:00 0
096a3000-096e5000 rw-p 00000000 00:00 0 [heap]
4616d000-4618c000 r-xp 00000000 08:06 4415 /usr/lib/ld-2.17.so
4618c000-4618d000 r--p 0001e000 08:06 4415 /usr/lib/ld-2.17.so
4618d000-4618e000 rw-p 0001f000 08:06 4415 /usr/lib/ld-2.17.so
46190000-46348000 r-xp 00000000 08:06 4643 /usr/lib/libc-2.17.so
46348000-46349000 ---p 001b8000 08:06 4643 /usr/lib/libc-2.17.so
46349000-4634b000 r--p 001b8000 08:06 4643 /usr/lib/libc-2.17.so
4634b000-4634c000 rw-p 001ba000 08:06 4643 /usr/lib/libc-2.17.so
4634c000-4634f000 rw-p 00000000 00:00 0
463d2000-463ed000 r-xp 00000000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1
463ed000-463ee000 r--p 0001a000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1
463ee000-463ef000 rw-p 0001b000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1
b7714000-b7715000 rw-p 00000000 00:00 0
b773f000-b7742000 rw-p 00000000 00:00 0
b7742000-b7743000 r-xp 00000000 00:00 0 [vdso]
bfc43000-bfc65000 rw-p 00000000 00:00 0 [stack]
qemu: terminating on signal 15 from pid 8740
main-loop: WARNING: I/O thread spun for 1000 iterations
*** Error in /usr/bin/iasl': double free or corruption (!prev): 0x09e5c3d0 *** ======= Backtrace: ========= /lib/libc.so.6[0x46205d12] /usr/bin/iasl[0x80a5a66] /usr/bin/iasl[0x80a2717] /usr/bin/iasl[0x80a284b] /usr/bin/iasl[0x805bf32] /usr/bin/iasl[0x8072352] /usr/bin/iasl[0x80726c1] /usr/bin/iasl[0x80725f5] /usr/bin/iasl[0x80491a9] /lib/libc.so.6(__libc_start_main+0xf3)[0x461a9963] /usr/bin/iasl[0x80491fd] ======= Memory map: ======== 08047000-0810d000 r-xp 00000000 08:06 48242 /usr/bin/iasl 0810d000-0810e000 r--p 000c5000 08:06 48242 /usr/bin/iasl 0810e000-0810f000 rw-p 000c6000 08:06 48242 /usr/bin/iasl 0810f000-08113000 rw-p 00000000 00:00 0 09e3c000-09e7e000 rw-p 00000000 00:00 0 [heap] 4616d000-4618c000 r-xp 00000000 08:06 4415 /usr/lib/ld-2.17.so 4618c000-4618d000 r--p 0001e000 08:06 4415 /usr/lib/ld-2.17.so 4618d000-4618e000 rw-p 0001f000 08:06 4415 /usr/lib/ld-2.17.so 46190000-46348000 r-xp 00000000 08:06 4643 /usr/lib/libc-2.17.so 46348000-46349000 ---p 001b8000 08:06 4643 /usr/lib/libc-2.17.so 46349000-4634b000 r--p 001b8000 08:06 4643 /usr/lib/libc-2.17.so 4634b000-4634c000 rw-p 001ba000 08:06 4643 /usr/lib/libc-2.17.so 4634c000-4634f000 rw-p 00000000 00:00 0 463d2000-463ed000 r-xp 00000000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 463ed000-463ee000 r--p 0001a000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 463ee000-463ef000 rw-p 0001b000 08:06 51367 /usr/lib/libgcc_s-4.8.2-20131212.so.1 b777d000-b777e000 rw-p 00000000 00:00 0 b77a8000-b77ab000 rw-p 00000000 00:00 0 b77ab000-b77ac000 r-xp 00000000 00:00 0 [vdso] bfbb1000-bfbd3000 rw-p 00000000 00:00 0 [stack] *** Error in/usr/bin/iasl': double free or corruption (!prev): 0x0926c410 ***
Note:
iasl -d HPET works OK.
Thanks,
Marcel
DefinitionBlock ("TEST.aml", "DSDT", 2, "FU", "BAR", 0x00000001)
{
Device(BLAH)
{
Name(Y, 0)
Method(X, 0, NotSerialized)
{
Store(0, Y) // old school: works
Y = 0 // new school: works
Store("blah", Debug) // old school: works
Debug = "blah" // new school: not working
}
}
}
Results in error:
11, 6126, syntax error, unexpected PARSEOP_EXP_EQUALS, expecting PARSEOP_EXP_DECREMENT or PARSEOP_EXP_INCREMENT
Sorry to bother you, but I have a question that the STAO table can be used only in a virtual machine environment? ( I made a STAO table but doesn't work for real OS)
There's an issue with infinite loop detection that stops my laptop from suspending successfully. It was already reported on https://bugzilla.kernel.org/show_bug.cgi?id=156501, and the relevant pull request can be found on #185. Nonetheless, this pull request was later moved into #196 and removed indefinitely. I would appreciate if anyone can take a look at this.
DefinitionBlock ("TEST.aml", "DSDT", 2, "FU", "BAR", 0x00000001)
{
Device(BLAH)
{
Name(X, 0)
Method (TEST, 2, NotSerialized)
{
If (LNotEqual (And (X, 0x03, Local1), Zero))
{
}
}
}
}
The above code compiles correctly (old school).
Then disassembles as (C-style):
DefinitionBlock ("test.aml", "DSDT", 2, "FU", "BAR", 0x00000001)
{
Device (BLAH)
{
Name (X, Zero)
Method (TEST, 2, NotSerialized)
{
If ((Local1 = (X & 0x03) != Zero)) {}
}
}
}
Note: misplaced parentheses.
Correct disassembly:
DefinitionBlock ("test.aml", "DSDT", 2, "FU", "BAR", 0x00000001)
{
Device (BLAH)
{
Name (X, Zero)
Method (TEST, 2, NotSerialized)
{
If ((Local1 = (X & 0x03)) != Zero) {}
}
}
}
But it also does not compile.
Results in errors:
test.dsl 8: If ((Local1 = (X & 0x03)) != Zero) {}
Error 6126 - syntax error, unexpected ')' ^
test.dsl 11:
Error 6126 - syntax error, unexpected '}', expecting $end and premature End-Of-File
ASL Input: test.dsl - 11 lines, 231 bytes, 7 keywords
Compilation complete. 2 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
DSDT is the usual one.
Look for example where EECD method is defined.
-dl correctly (?) comments /* _SB_.PCI0.SBRG.EC0_.P6CH */, while output without this switch lacks it.
I encountered a use-after-free while working with the fuchsia operating system, when booting on a Intel NUC with AddressSanitizer (asan) enabled. Fuchsia's import of acpica is 2-3 years old at this point, but it looks like the issue is still present in the current version of acpica.
The use-after-free issue occurs while calling AcpiTerminate, during teardown of the global namespace. The series of events which occur are:
Hello!
I think it is some bug with ElseIf operator.
Example:
Store (B1PR, Local0)
ShiftLeft (Local0, 0x08, Local1)
And (Local1, 0xFF00, Local1)
ShiftRight (Local0, 0x08, Local0)
Or (Local0, Local1, Local0)
If (LEqual (Local0, 0xFFFF))
{
Store (0xFFFFFFFF, Index (STAT, One))
}
ElseIf (LGreaterEqual (Local0, 0x8000))
{
XOr (Local0, 0xFFFF, Local0)
Increment (Local0)
}
Should be like this, if I use the 4.0A version:
Store (B1PR, Local0)
ShiftLeft (Local0, 0x08, Local1)
And (Local1, 0xFF00, Local1)
ShiftRight (Local0, 0x08, Local0)
Or (Local0, Local1, Local0)
If (LEqual (Local0, 0xFFFF))
{
Store (0xFFFFFFFF, Index (STAT, One))
}
Else
{
If (LGreaterEqual (Local0, 0x8000))
{
XOr (Local0, 0xFFFF, Local0)
Increment (Local0)
}
Store (Local0, Index (STAT, One)) // Here. It was lost with ElseIf.
}
Example code attached.
Samsung_R522.zip
*** Sorry, I cant do the correction, it is glitching with code braces :(
So.. Tl;dr
Just try to decompile the dsdt table I sent here, using the facp file I uploaded here for external symbols.
Yes, I know I wouldn't be expected to use that with -e switch, but I was hoping resolving the last two UnkknownObj (wherever they are defined) could help shedding light on the mystery about dev dull volition.
I've tried R03_03_17 release and it produces the following error when compiling on macOS 10.12:
gcc -c -D_APPLE -D_GNU_SOURCE -I../../../source/include -DACPI_ASL_COMPILER -I../../../source/compiler -Iobj -std=c99 -Wall -Wbad-function-cast -Wdeclaration-after-statement -Werror -Wformat=2 -Wmissing-declarations -Wmissing-prototypes -Wstrict-aliasing=0 -Wstrict-prototypes -Wswitch-default -Wpointer-arith -Wundef -Waddress -Waggregate-return -Winit-self -Winline -Wmissing-declarations -Wmissing-field-initializers -Wnested-externs -Wold-style-definition -Wno-format-nonliteral -Wredundant-decls -Wempty-body -O2 -D_FORTIFY_SOURCE=2 -o obj/asltree.o ../../../source/compiler/asltree.c
../../../source/compiler/asltree.c:298:53: error: address of array
'Gbl_CommentState.Latest_Parse_Node->Asl.ParseOpName' will always evaluate
to 'true' [-Werror,-Wpointer-bool-conversion]
if (Gbl_CommentState.Latest_Parse_Node->Asl.ParseOpName)
~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
1 error generated.
make[1]: *** [obj/asltree.o] Error 1
make: *** [iasl] Error 2
In source/include/actbl1.h, ACPI_TABLE_MADT includes a flag field.
The preprocessor define ACPI_MADT_PCAT_COMPAT specifies a mask for the PCAT_COMPAT flag while ACPI_MADT_DUAL_PIC and ACPI_MADT_MULTIPLE_APIC specify the values of said flag.
My interpretation of said defines is that ACPI_MADT_DUAL_PIC indicates the presence of dual 8259 PICs, whereas ACPI_MADT_MULTIPLE_APIC indicates their absence.
i.e. hasDualPics = (madt->Flags & ACPI_MADT_PCAT_COMPAT) == ACPI_MADT_DUAL_PIC
However, ACPI_MADT_DUAL_PIC is defined as 0 while the ACPI specification says regarding the PCAT_COMPAT flag:
A one indicates that the system also has a PC-AT-compatible dual-8259 setup.
(ACPI 6.1, Table 5-45 Multiple APIC Flags, p. 144)
I am probably misunderstanding or misreading something but I would appreciate any insight.
This appears in a certain OEM DSDT, as disassembled with iasl previous to the if else merging commit:
Method (CWAK, 1, NotSerialized)
{
^PCI0.LPCB.EC0.WLSW ()
^PCI0.LPCB.EC0.WWSW ()
^PCI0.LPCB.EC0.RLED ()
If (LEqual (Arg0, 0x04))
{
If (LNotEqual (PIDC (0x21), Ones))
{
If (LEqual (^PCI0.LPCB.EIOR (One, 0x05, 0x04F4), Zero)) {}
}
Else
{
}
}
If (LNotEqual (PIDC (0x04), Ones))
{
HSWK (Arg0)
}
CBDM ()
}
The current code gets confused and enters an endless loop, creating a rather large file until I decide to Ctrl+C to stop it:
Method (CWAK, 1, NotSerialized)
{
^PCI0.LPCB.EC0.WLSW ()
^PCI0.LPCB.EC0.WWSW ()
^PCI0.LPCB.EC0.RLED ()
If ((Arg0 == 0x04))
{
If ((PIDC (0x21) != Ones))
{
If ((^PCI0.LPCB.EIOR (One, 0x05, 0x04F4) == Zero)) {}
}
ElseIf ((PIDC (0x04) != Ones))
{
HSWK (Arg0)
}
}
((PIDC (0x04) != Ones))
{
HSWK (Arg0)
}
}
((PIDC (0x04) != Ones))
{
HSWK (Arg0)
}
}
((PIDC (0x04) != Ones))
{
HSWK (Arg0)
}
}
((PIDC (0x04) != Ones))
{
HSWK (Arg0)
}
}
((PIDC (0x04) != Ones))
{
HSWK (Arg0)
}
}
((PIDC (0x04) != Ones))
{
HSWK (Arg0)
}
}
((PIDC (0x04) != Ones))
{
HSWK (Arg0)
}
}
... and it continues ... forever...
I can probably work up a small example, or provide the DSDT.aml binary, but maybe just the code above helps discover the problem.
I de-compiled DSDT.asl using the following command:
iasl -dl DSDT.aslI then tried to recompile DSDT.dsl using the following command:
iasl DSDT.dslHowever, it gave me this error:
❯ iasl DSDT.dsl
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20180427(RM)
Copyright (c) 2000 - 2018 Intel Corporation
Compiler aborting due to parser-detected syntax error(s)
DSDT.dsl 349: Name (SS4, One)
Error 6126 - ^ syntax error, unexpected PARSEOP_NAMEI have tried with IASL 20160422 as well, but it gave me the exact same error.
Here is the line in question:
Name (SS4, One)
And the code before and after it:
Name (SS1, 0x00)
Name (SS2, 0x00)
Name (SS3, One)
One
Name (SS4, One)
One
OperationRegion (GNVS, SystemMemory, 0x4FBF2000, 0x0802)
Any help would be greatly appreciated. I am using the DSDT from a Lenovo ThinkPad P72 - I can provide more information as needed.
Thanks in advance.
Similar to #413, is another regression, but I do not have a lot of recent versions to be sure that it was caused by the latest update. System FACP.dsl.zip
./iasl System\ FACP.dsl System\ FACP.aml
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20181003
Copyright (c) 2000 - 2018 Intel Corporation
=================================================================
==11979==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000c8f at pc 0x00010524e7ed bp 0x7ffeeaa656f0 sp 0x7ffeeaa656e8
READ of size 1 at 0x602000000c8f thread T0
#0 0x10524e7ec in DtTrim (iasl:x86_64+0x1000b47ec)
#1 0x10524d59e in DtParseLine (iasl:x86_64+0x1000b359e)
#2 0x10524d1dd in DtScanFile (iasl:x86_64+0x1000b31dd)
#3 0x105249d8f in DtDoCompile (iasl:x86_64+0x1000afd8f)
#4 0x1051ff500 in AslDoOneFile (iasl:x86_64+0x100065500)
#5 0x1051d32b3 in main (iasl:x86_64+0x1000392b3)
#6 0x7fff7d561014 in start (libdyld.dylib:x86_64+0x1014)
0x602000000c8f is located 1 bytes to the left of 1-byte region [0x602000000c90,0x602000000c91)
allocated by thread T0 here:
#0 0x105574497 in wrap_calloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x57497)
#1 0x1051bb34e in UtLocalCalloc (iasl:x86_64+0x10002134e)
#2 0x10524d586 in DtParseLine (iasl:x86_64+0x1000b3586)
#3 0x10524d1dd in DtScanFile (iasl:x86_64+0x1000b31dd)
#4 0x105249d8f in DtDoCompile (iasl:x86_64+0x1000afd8f)
#5 0x1051ff500 in AslDoOneFile (iasl:x86_64+0x100065500)
#6 0x1051d32b3 in main (iasl:x86_64+0x1000392b3)
#7 0x7fff7d561014 in start (libdyld.dylib:x86_64+0x1014)
SUMMARY: AddressSanitizer: heap-buffer-overflow (iasl:x86_64+0x1000b47ec) in DtTrim
Shadow bytes around the buggy address:
0x1c0400000140: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x1c0400000150: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x1c0400000160: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x1c0400000170: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x1c0400000180: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
=>0x1c0400000190: fa[fa]01 fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c04000001a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c04000001b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c04000001c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c04000001d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c04000001e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==11979==ABORTING
Abort trap: 6
Hi!
I tried build latest version of iasl (20141107) and get this error.
Change OPT_CFLAGS += -O2 -D_FORTIFY_SOURCE=2 to OPT_CFLAGS += -O2 in generate/unix/Makefile.config fixed this for me.
Thanks.
Consider this example:
DefinitionBlock ("test.aml", "DSDT", 2, "TEST", "TEST", 0)
{
Method(TEST)
{
Store(0xFF00, Local0)
Store(Local0, Local1)
Subtract(0xFFFF, Local1, Local1)
Subtract(0xFFFF, Local1, Local2)
}
}
Save to test.dsl, compile with 'iasl test.dsl'. Disassembly with 'iasl -dl test.aml' result (correct):
DefinitionBlock ("test.aml", "DSDT", 2, "TEST", "TEST", 0x00000000)
{
Method (TEST, 0, NotSerialized)
{
Store (0xFF00, Local0)
Store (Local0, Local1)
Subtract (0xFFFF, Local1, Local1)
Subtract (0xFFFF, Local1, Local2)
}
}
Disassembly with 'iasl -d test.aml' result:
DefinitionBlock ("test.aml", "DSDT", 2, "TEST", "TEST", 0x00000000)
{
Method (TEST, 0, NotSerialized)
{
Local0 = 0xFF00
Local1 = Local0
Local1 -= 0xFFFF
Local2 = (0xFFFF - Local1)
}
}
The line:
Local1 -= 0xFFFF
It is wrong. Should be (as the case with Local2 result):
Local1 = (0xFFFF - Local1)
Hello!
Some bug encountered with losing _T_x Symbols.
Example:
Method (GIT0, 1, NotSerialized)
{
Name (_T_0, Zero)
Store (And (Arg0, 0xFFFF), _T_0)
If (LEqual (_T_0, 0x05))
{
Store (GNVS (0x173E), ASB1)
}
Else
{
Store (Zero, ASB0)
}
}
And with 20170119 version the code is losing Name (_T_0, Zero) at the beginning, so the code reaches an error "Object doesn't exist"
Example:
Method (GIT0, 1, NotSerialized)
{
Store (And (Arg0, 0xFFFF), _T_0)
If (LEqual (_T_0, 0x05))
{
Store (GNVS (0x173E), ASB1)
}
Else
{
Store (Zero, ASB0)
}
}
Also take a look to the 5781 line with Store (RTMP (TPMP), Store (RTNP, TPNP) disassembled code, plz! Why it does so?
dsdt1.aml.zip
When use the linux os to build the ACPICA would have a error as below.
bison -y -pAslCompiler -o/dev/null --defines=obj/aslcompiler.y.h obj/aslcompiler.y
bison: option '--defines' doesn't allow an argument
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.