Myles Watson wrote:
On Wed, Mar 17, 2010 at 6:17 PM, Carl-Daniel Hailfinger
<[email protected]
<mailto:[email protected]>> 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
assembler.)
I'm not sure I like this solution.
MM
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
