Hey Sebastian,
On 2/1/2020 9:23 AM, Sebastian Huber wrote:
> Hello Jeff,
>
> ----- Am 14. Jan 2020 um 17:37 schrieb Jeff Kubascik
> jeff.kubas...@dornerworks.com:
>
>> Hello,
>>
>> I have noticed a change in the linker section ".rtemsrwset" alignment which
>> has
>> affected the zImage header that was added with the arm/xen BSP. The zImage
>> header uses the bsp_section_data_end symbol to determine the end of the
>> image. I
>> was able to track this change to the commit 234d155e linkersets: Revert to
>> zero-length arrays.
>>
>> Here is the readelf output of the ticker.exe application just prior before
>> commit
>>
>> Section Headers:
>> [Nr] Name Type Addr Off Size ES Flg Lk Inf
>> Al
>> [15] .rtemsstack NOBITS 40100000 01358c 001000 00 WA 0 0
>> 64
>> [16] .data PROGBITS 40101000 101000 0004e0 00 WA 0 0
>> 8
>> [17] .rtemsrwset PROGBITS 401014e0 1014e0 000000 00 0 0
>> 1
>>
>> Here is the output with the commit
>>
>> Section Headers:
>> [Nr] Name Type Addr Off Size ES Flg Lk Inf
>> Al
>> [15] .rtemsstack NOBITS 40100000 01358c 001000 00 WA 0 0
>> 64
>> [16] .data PROGBITS 40101000 101000 0004e0 00 WA 0 0
>> 8
>> [17] .rtemsrwset PROGBITS 40101500 101500 000000 00 WA 0 0
>> 64
>>
>> This shows that the alignment of the ".rtemsrwset" section changed from 1
>> byte
>> to 64 bytes. This changes the start address of the section to be aligned,
>> even
>> though the section is empty.
>>
>> The bsp_section_data_end symbol is located at the end of the ".rtemsrwset"
>> section. If the section is empty, the bsp_section_data_end symbol will
>> contain
>> the start address of the section.
>>
>> .data : ALIGN_WITH_INPUT {
>> bsp_section_data_begin = .;
>> *(.data .data.* .gnu.linkonce.d.*)
>> SORT(CONSTRUCTORS)
>> } > REGION_DATA AT > REGION_DATA_LOAD
>> .data1 : ALIGN_WITH_INPUT {
>> *(.data1)
>> } > REGION_DATA AT > REGION_DATA_LOAD
>> .rtemsrwset : ALIGN_WITH_INPUT {
>> KEEP (*(SORT(.rtemsrwset.*)))
>> bsp_section_data_end = .;
>> } > REGION_DATA AT > REGION_DATA_LOAD
>>
>> When I convert the ticker.exe elf to a binary with objcopy, the binary
>> doesn't
>> include the ".rtemsrwset" section, since it's empty. As a result, the length
>> of
>> the binary doesn't match the bsp_section_data_end symbol. This is a problem
>> for
>> some zImage loaders that verify the image length.
>>
>> I'm not certain what would be the best way to fix the zImage header. Is
>> there a
>> different symbol that I should be using to get the end of the image? Maybe
>> this
>> is a bug with the linker script?
>
> there is no bug in the linker script. In wkspace.c there is this linker set
> declared:
>
> RTEMS_LINKER_RWSET(
> _Per_CPU_Data,
> RTEMS_ALIGNED( CPU_CACHE_LINE_BYTES ) char
> );
>
> So, the .rtemsrwset contains an empty _Per_CPU_Data set which is properly
> aligned.
>
> In uniprocessor configuration, the cache alignment is superfluous. I will fix
> this.
If I understand correctly, the plan is to negate/undo the cache alignment change
that was introduced in commit 234d155e for uni-processor configuration? If that
is correct, it should fix the issue.
> Why don't you use the file size of your binary created by objcopy to set the
> image size?
>
This would require that I modify the binary/elf contents manually after linking,
as the size field is stored in the zImage header near the start of the
application.
For development, I was padding the binary blob up to cache alignment match the
expected size in the zImage header. While this worked, it was clunky and
tedious.
Sincerely,
Jeff Kubascik
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
