arch/x86: make use of z_bss_zero() and z_data_copy()

[ghost]

For reasons that are not immediately obvious, the 32-bit x86 code does not use the kernel functions supplied to zero the BSS and initialize other data regions. This should probably be changed.

Note that at the same time, x86-optimized implementations of memset() memcpy() et al. could/should be added to the minimal libc if gcc doesn't supply decent builtin implementations.

[andrewboie]

For reasons that are not immediately obvious, the 32-bit x86 code does not use the kernel functions supplied to zero the BSS and initialize other data regions. This should probably be changed.

Think this was left in because memset()/memcpy() weren't using SSE like the handcrafted assembly does for x86.

Note that at the same time, x86-optimized implementations of memset() memcpy() et al. could/should be added to the minimal libc if gcc doesn't supply decent builtin implementations.

AFAIK GCC currently isn't, would be great to remedy this.

[ghost]

@andrewboie It looks like, at a minimum, the zeroing of the app_shmem stuff in ia32/crt0.S is redundant, as this recurs again at z_app_shmem_bss_zero(), no?

[andrewboie]

@andrewboie It looks like, at a minimum, the zeroing of the app_shmem stuff in ia32/crt0.S is redundant, as this recurs again at z_app_shmem_bss_zero(), no?

@gnuless The code in crt0.S does the XIP copy of the app_smem data into the proper place if XIP is turned on, to copy it out of ROM. I'm assuming you're looking at around line 232 in crt0.S. This could easily use z_data_copy(). IIRC this sits right next to kernel data and the copy could probably be combined.

z_app_shmem_bss_zero() is special, it goes through the subsections in the app_smem data section, which is really a set of:

---------------  <-- _app_smem_start
partition1 data
---------------
partition1 bss
---------------
partition2 data
---------------
partition2 bss
---------------
...
---------------
partitionN data
---------------
partitionN bss
--------------- <-- _app_smem_end

And zeroes just those BSS sub-sections.
This is organized this way since you set MPU/MMU regions, for example for partition1, to cover both data and bss for the individual partitions, so they are adjacent. So a thread granted access to partition1 would have an MMU/MPU region granted which covered both partition1 data and partition1 bss.

[ghost]

Yep, whoops, I was mistaken there.