Challenge accepted. They aren't because they are defined with ABI/compiler:
- 64-bit data type alignment is different in 32-bit ABI (4 bytes) and
different in 64-bit ABI (8 bytes). Not even sure how the other ABIs got this.
- CB structures like framebuffer struct are not padded to the size
compiler likes.
The "packed" attribute would be bit dangerous because then compiler might complain like "error: taking address of packed member of 'struct cb_framebuffer' may result in an unaligned pointer value [-Werror=address-of-packed-member]"
Alternatively one could add "pad[2]" member to the end to the fb structure to fix this, but maybe this will break some payloads which don't check the ->size of specific tag...
Anyway, hope this illustrates the problem a bit.
Nice catch! Regardless of the upshot of this it's worth fixing this problem in the coreboot tables implementation. I'm not very knowledgeable on the topic but don't a lot of CPU ARCH support unaligned pointer access in hardware but it slows things down? The way you find coreboot table structs is by looping over ->size, since payloads may not know some tags. So aligning the size up to 8 bytes when generating the coreboot tables should do the trick.
Kind regards Arthur
On Tue, Apr 19, 2022 at 10:44 AM Rudolf Marek r.marek@assembler.cz wrote:
Dne 12. 04. 22 v 0:04 Peter Stuge napsal(a):
I propose that coreboot tables are a good alternative - fight me! :)
Challenge accepted. They aren't because they are defined with ABI/compiler:
- 64-bit data type alignment is different in 32-bit ABI (4 bytes) and
different in 64-bit ABI (8 bytes). Not even sure how the other ABIs got this.
- CB structures like framebuffer struct are not padded to the size
compiler likes.
The "packed" attribute would be bit dangerous because then compiler might complain like "error: taking address of packed member of 'struct cb_framebuffer' may result in an unaligned pointer value [-Werror=address-of-packed-member]"
Alternatively one could add "pad[2]" member to the end to the fb structure to fix this, but maybe this will break some payloads which don't check the ->size of specific tag...
Anyway, hope this illustrates the problem a bit.
Thanks, Rudolf
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org