[coreboot] [Patch] remove some warnings

Mark Marshall mark.marshall at csr.com
Thu Mar 18 11:35:52 CET 2010

Myles Watson wrote:
> On Wed, Mar 17, 2010 at 6:17 PM, Carl-Daniel Hailfinger 
> <c-d.hailfinger.devel.2006 at gmx.net 
> <mailto:c-d.hailfinger.devel.2006 at gmx.net>> wrote:
>     Hi Segher,
>     you're probably able to solve this one easily.
>     On 18.03.2010 00:45, Myles Watson wrote:
>      >>> -extern unsigned char AmlCode[];
>      >>> +extern void* AmlCode;
>      >>>
>      >>>
>      >>>  So AmlCode is used as a void * pointing to the address 0x54445344
>      >> What is it, you want to do?
>      >>
>      >>
>      > Get rid of the type punned warning that gcc gives for that code where
>      > AmlCode gets cast to acpi_header_t.
>      >
>     Could __attribute__((may_alias)) help?
> I'd rather not use an attribute if we can just use a cast.
> It seems to work to have an intermediate void*:
>      void_ptr = &AmlCode_ssdt;
>      current += ((acpi_header_t *)void_ptr)->length;
> It compiles without warning and is functionally correct, but it may be 
> too ugly.  I'm still surprised that it needs to be &AmlCode_ssdt.  I 
> really expected Amlcode_ssdt to be a cast-able pointer.

If you have this in one C file:

   static const char AmlCode[] = {0,1,2,3,4,5,6,7};

You can then have this in another C file, which is what you want:

   struct AmlCode_s
	/* stuff ? */
	int a, b;

   extern const struct AmlCode_s AmlCode;

This will mean that you've got wrong debug info, of course, but it is 
what you seem to want.  The first file defines a symbol, and the second 
files says that a symbol is defined somewhere else.  The types don't 
match, but the C compiler doesn't know / care about that.

(Image what would happen if you were to replace the first file with 

I'm not sure I like this solution.


More information about the coreboot mailing list