> On 17/02/2021 16:32, Kinsey Moore wrote: >>> .section .rtemsroset.s.begin,"a" >>> .align 8 >>> .type _Linker_set_s_begin, %object >>> .size _Linker_set_s_begin, 0 >>> _Linker_set_s_begin: >>> .section .rtemsroset.s.end,"a" >>> .align 8 >>> .type _Linker_set_s_end, %object >>> .size _Linker_set_s_end, 0 >>> _Linker_set_s_end: >>> .ident "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB >>> 61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)" >>>> <snip> >>>> >>> I would remove the SUBALIGN() from the linker script. You can also add a >>> new test case for splinkersets01 similar to struct s from above. Then we >>> should check if the test fails on aarch64 and why it fails. >> The example above actually shows the issue I'm having in _Linker_set_i_begin >> and _Linker_set_i_end. The alignment expands for the larger struct, but does >> not shrink for data types smaller than 8 bytes, leaving padding that the >> test interprets as additional space in the linker set. > > I still don't see why a larger alignment is an issue. The begin/end > objects have a size of zero. Where do you observe a padding?
Even when the begin/end objects have a size of 0, they're aligned out to 8 bytes forcing empty bytes if the content does not exactly fill a multiple of 8 bytes. Those non-content bytes are counted as part of the section. Kinsey _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
