----- Am 4. Feb 2020 um 21:02 schrieb Jeff Kubascik
jeff.kubas...@dornerworks.com:
> 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.
I already fixed this:
https://git.rtems.org/rtems/commit/?id=9e4f21b927e8a81df8044806e88128388911e123
It fixes your problem only in certain cases.
>
>> 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.
In the ELF file, there is no problem. Why can't you use the file size of the
objcopy output and write this in your zImage header?
>
> 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.
Yes.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
