Date: Tue, 16 Oct 2001 11:34:20 -0700 From: "Grover, Andrew" <andrew.grover@intel.com> To: "'Peter Wemm'" <peter@wemm.org>, Mike Smith <msmith@FreeBSD.ORG> Cc: Marcel Moolenaar <marcel@xcllnt.net>, ia64@FreeBSD.ORG Subject: RE: Faulty ACPI debug code [was: Re: Booting a dual ...] Message-ID: <59885C5E3098D511AD690002A5072D3C42D66E@orsmsx111.jf.intel.com>
index | next in thread | raw e-mail
Hi Peter,
Thanks for the problem reports. Our code can't use GCC extensions and
maintain ANSI C conformance, but it sure looks like using them briefly and
cleaning up the code would be a good thing to do...;-)
Regards -- Andy
> -----Original Message-----
> From: Peter Wemm [mailto:peter@wemm.org]
> Sent: Sunday, October 14, 2001 11:37 PM
> To: Mike Smith
> Cc: Marcel Moolenaar; ia64@FreeBSD.ORG; Andrew.Grover@intel.com
> Subject: Re: Faulty ACPI debug code [was: Re: Booting a dual ...]
>
>
> Mike Smith wrote:
> >
> > I've copied the Intel ACPI CA folks on this, since I'm sure
> they'll be
> > interested.
>
> While on the subject, If you add printf format checking,
> there are some
> *nasty* problems in the debug printfs. They fixed about 2/3
> of them a few
> months ago but left the others alone. They're still trying to printf
> a 64 bit int with %p on the i386 platform (which causes stack
> misalignment).
>
> ie:
> --- acutils.h 2001/10/04 23:12:11 1.1.1.11
> +++ acutils.h 2001/10/15 06:00:36
> @@ -436,5 +436,5 @@
> ACPI_DEBUG_PRINT_INFO *DbgInfo,
> char *Format,
> - ...);
> + ...) __attribute__ ((format (printf, 4, 5)));
>
> void
> @@ -444,5 +444,5 @@
> ACPI_DEBUG_PRINT_INFO *DbgInfo,
> char *Format,
> - ...);
> + ...) __attribute__ ((format (printf, 4, 5)));
>
>
> Additional warnings about the function in question:
>
> dsopcode.c: In function `AcpiDsGetRegionArguments':
> dsopcode.c:325: warning: char format, different type arg (arg 5)
>
> Line 325:
> ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, "[%4.4s] OpRegion Init
> at AML %p[%x]\n",
> &Node->Name, ExtraDesc->Extra.AmlStart,
> *(UINT32*) ExtraDesc->Extra.AmlStart));
>
> typedef struct acpi_node
> {
> UINT32 Name; /* ACPI Name,
> always 4 chars per ACPI spec */
> } ACPI_NAMESPACE_NODE;
>
> This is passing an &UINT32 instead of 'char *'. This had better be
> little endian.
>
> A sample of more problems:
>
> evevent.c:559: warning: format argument is not a pointer (arg 6)
> evevent.c:559: warning: format argument is not a pointer (arg 8)
> ACPI_DEBUG_PRINT ((ACPI_DB_INFO, "GPE registers: %X@%p
> (Blk0) %X@%p (Blk1)\n",
> Gpe0RegisterCount, AcpiGbl_FADT->XGpe0Blk.Address,
> Gpe1RegisterCount,
> AcpiGbl_FADT->XGpe1Blk.Address));
> XGpe0Blk.Address and XGpe1Blk.Address are 64 bit integers,
> not pointers.
> This causes stack misalignment.
>
> exdump.c:348: warning: long int format, different type arg (arg 5)
> exdump.c:366: warning: long int format, different type arg (arg 5)
> ACPI_DEBUG_PRINT_RAW ((ACPI_DB_INFO, " value is [%ld]",
>
> EntryDesc->Integer.Value));
> The above two are moderately harmless unless you are compiling on
> gcc where long == 64 bit.
>
> exdump.c:491: warning: format argument is not a pointer (arg 5)
> ACPI_DEBUG_PRINT_RAW ((ACPI_DB_INFO, " base %p
> Length %X\n",
> EntryDesc->Region.Address, EntryDesc->Region.Length));
> This is a fatal UINT64 / 32 bit %p mixup.
>
> exprep.c:434: warning: char format, different type arg (arg 6)
> exprep.c:542: warning: char format, different type arg (arg 6)
> exprep.c:633: warning: char format, different type arg (arg 6)
> ACPI_DEBUG_PRINT ((ACPI_DB_INFO, "set NamedObj %p (%4.4s)
> val = %p\n",
> Node, &(Node->Name), ObjDesc));
> More &UINT32 vs char *
>
> exresolv.c:239: warning: long unsigned int format, different
> type arg (arg 11)
> relatively harmless long / int mixup.
>
> exresop.c:248: warning: unsigned int format, pointer arg (arg 5)
> ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Internal -
> null stack entry at %X\n",
> StackPtr));
> This should actually use %p
>
> hwregs.c:573: warning: format argument is not a pointer (arg 6)
> ACPI_DEBUG_PRINT ((ACPI_DB_IO, "PM2 control: Read %X
> from %p\n",
> RegisterValue, ACPI_GET_ADDRESS
> (AcpiGbl_FADT->XPm2CntBlk.Address)));
> Another fatal (for debugging) UINT64 / %p mixup
>
> hwregs.c:583: warning: format argument is not a pointer (arg 6)
> ACPI_DEBUG_PRINT ((ACPI_DB_IO, "About to write
> %04X to %p\n", RegisterValue,
> AcpiGbl_FADT->XPm2CntBlk.Address));
> same again
>
> hwregs.c:597: warning: format argument is not a pointer (arg 6)
> ACPI_DEBUG_PRINT ((ACPI_DB_IO, "PM_TIMER: Read %X from %p\n",
> RegisterValue, ACPI_GET_ADDRESS
> (AcpiGbl_FADT->XPmTmrBlk.Address)));
> and again...
>
> nsdump.c:570: warning: unsigned int format, different type arg (arg 6)
> ACPI_DEBUG_PRINT_RAW ((ACPI_DB_TABLES, " HID:
> %.8X, ADR: %.8X, Status: %x\n",
> Info.HardwareId, Info.Address,
> Info.CurrentStatus));
> This is an interesting one... Info.HardwareId is NATIVE_CHAR
> HardwareId[9];
> It should probably be %p.
>
> This is a sample of the problems that using printf type checking
> turns up. I have only included a small fraction of the instances of
> each problem as an example only. Some only mess up debugging output,
> and cause lots of wasted time due to wild goose chases when bogus
> values are reported. (printf %p of a uint64 always prints 0 on i386
> with gcc (eg: on freebsd and linux))
>
> Cheers,
> -Peter
> --
> Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com;
> peter@netplex.com.au
> "All of this is for nothing if we don't go to the stars" - JMS/B5
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ia64" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59885C5E3098D511AD690002A5072D3C42D66E>