Incremental build with config changes can produce an invalid binary when userspace is enabled #42184
Assignees
Labels
area: Build System
area: Kernel
area: newlib
Newlib C Standard Library
area: Userspace
Userspace
bug
The issue is a bug, or the PR is fixing a bug
priority: medium
Medium impact/importance bug
Comments
|
tagging @stephanosio |
stephanosio
added
area: Kernel
area: newlib
@carlocaione Something is definitely wrong there. That issue is observed only when you do an incremental (non-clean) build after enabling the newlib, meaning this is a build system issue (cc @tejlmand @SebastianBoe). If you do a clean build after enabling the newlib, you get the following error message, which is expected because the newlib with userspace requires the kernel dynamic allocation feature (see #40686 (comment)). Also note that the newlib + userspace combo is currently tested by the |
tejlmand
added
priority: medium
stephanosio
changed the title
stephanosio
changed the title
tejlmand
added a commit
to tejlmand/zephyr
that referenced
this issue
Feb 3, 2022
Fixes: zephyrproject-rtos#42184 This commit fixes dependency issues related to kobject hash generation. Absolute path is ensured in cases where OUTPUT was provided with absolute path, as `${CMAKE_CURRENT_BINARY_DIR}`. DEPENDS referring to same file has been updated to also use `${CMAKE_CURRENT_BINARY_DIR}` to ensure they reference identical locations. The custom command renaming sections in kobject_hash.o and creating kobject_hash_renamed.o has been updated to depends on the target objects of kobj_hash_output_lib in addition to the library itself. This is needed because kobj_hash_output_lib is not a real library, and thus no library is updated when this target rebuilds. Instead the dependency must be on the object files created by kobj_hash_outplut_lib. This ensures that when object files gets rebuilt then the section renaming will also take place. The reason why both the object library itself, and its object files are required as dependencies has to do with build generators. The library is needed to ensure Makefiles can correctly have a target to invoke when the output of the custom command is missing. The object files dependency is required to ensure that custom commands are correctly brought up-to-date when the objects changes. Similar, the custom command executing gen_kobject_placeholders.py depending of kobj_prebuilt_hash_output_lib has been updated to also depend on the object files created by kobj_prebuilt_hash_output_lib. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
carlescufi
pushed a commit
that referenced
this issue
Feb 4, 2022
Fixes: #42184 This commit fixes dependency issues related to kobject hash generation. Absolute path is ensured in cases where OUTPUT was provided with absolute path, as `${CMAKE_CURRENT_BINARY_DIR}`. DEPENDS referring to same file has been updated to also use `${CMAKE_CURRENT_BINARY_DIR}` to ensure they reference identical locations. The custom command renaming sections in kobject_hash.o and creating kobject_hash_renamed.o has been updated to depends on the target objects of kobj_hash_output_lib in addition to the library itself. This is needed because kobj_hash_output_lib is not a real library, and thus no library is updated when this target rebuilds. Instead the dependency must be on the object files created by kobj_hash_outplut_lib. This ensures that when object files gets rebuilt then the section renaming will also take place. The reason why both the object library itself, and its object files are required as dependencies has to do with build generators. The library is needed to ensure Makefiles can correctly have a target to invoke when the output of the custom command is missing. The object files dependency is required to ensure that custom commands are correctly brought up-to-date when the objects changes. Similar, the custom command executing gen_kobject_placeholders.py depending of kobj_prebuilt_hash_output_lib has been updated to also depend on the object files created by kobj_prebuilt_hash_output_lib. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is reproducible on
qemu_x86_64andqemu_cortex_a53. Derived from #42106.Compile
samples/userspace/hello_world_user+CONFIG_NEWLIB_LIBC.On
qemu_x86_64:On
qemu_cortex_a53:In both cases
z_stack_is_user_capable(stack)is returningNULL.In particular what's returning
NULLisz_object_lookup():The
(str == s)comparison is failing because while thestris correctly carrying the address of thestack, the value ofsretrieved from thewordlisttable is wrong.In particular in
swe found the address of the stack as it would have been without NEWLIBC enabled.My theory is that the
wordlistis created at the wrong time during linking (maybe too soon?) so address used in there is not definitive and wrong with respect to the addresses in the final image.The text was updated successfully, but these errors were encountered: