summaryrefslogtreecommitdiff
path: root/doc/api/linker_lists.rst
AgeCommit message (Collapse)Author
2025-07-08kbuild: Bump the build system to 5.1Ilias Apalodimas
Our last sync with the kernel was 5.1. Even that was a partial one as some patches from 4.x kernels were already missing making the transition to a modern kbuild infeasible. We are so out of sync now, that tracking the patches and backporting them one by one makes little sense and it's going to take ages. This is an attempt to sync up Makefile[.lib/.kbuild]. Unfortunately due to sheer amount of patches this is not easy to review, but that's what we decided during a community call. One of the biggest changes is get rid of partial linking entirely and build .a archives isntead of .o. We diaviate from the kernel on that. Instead of calling a custom script to create the archive symbol table, we call ar with rcTP (isntead of rcSTP) since we want a resulting archive that's sauble with the linker. The only affected platforms are PPC ones. Unfortunately I don't have any of them around to test, but the objdump of the resulting files -- arch/powerpc/lib/built-in.[oa] looks identical. Signed-off-by: Ilias Apalodimas <[email protected]>
2022-06-23linker_lists: Rename sections to remove . prefixAndrew Scull
Rename the sections used to implement linker lists so they begin with '__u_boot_list' rather than '.u_boot_list'. The double underscore at the start is still distinct from the single underscore used by the symbol names. Having a '.' in the section names conflicts with clang's ASAN instrumentation which tries to add redzones between the linker list elements, causing expected accesses to fail. However, clang doesn't try to add redzones to user sections, which are names with all alphanumeric and underscore characters. Signed-off-by: Andrew Scull <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2020-12-18linker_lists: Fix alignment issueSimon Glass
The linker script uses alphabetic sorting to group the different linker lists together. Each group has its own struct and potentially its own alignment. But when the linker packs the structs together it cannot ensure that a linker list starts on the expected alignment boundary. For example, if the first list has a struct size of 8 and we place 3 of them in the image, that means that the next struct will start at offset 0x18 from the start of the linker_list section. If the next struct has a size of 16 then it will start at an 8-byte aligned offset, but not a 16-byte aligned offset. With sandbox on x86_64, a reference to a linker list item using ll_entry_get() can force alignment of that particular linker_list item, if it is in the same file as the linker_list item is declared. Consider this example, where struct driver is 0x80 bytes: ll_entry_declare(struct driver, fred, driver) ... void *p = ll_entry_get(struct driver, fred, driver) If these two lines of code are in the same file, then the entry is forced to be aligned at the 'struct driver' alignment, which is 16 bytes. If the second line of code is in a different file, then no action is taken, since the compiler cannot update the alignment of the linker_list item. In the first case, an 8-byte 'fill' region is added: .u_boot_list_2_driver_2_testbus_drv 0x0000000000270018 0x80 test/built-in.o 0x0000000000270018 _u_boot_list_2_driver_2_testbus_drv .u_boot_list_2_driver_2_testfdt1_drv 0x0000000000270098 0x80 test/built-in.o 0x0000000000270098 _u_boot_list_2_driver_2_testfdt1_drv *fill* 0x0000000000270118 0x8 .u_boot_list_2_driver_2_testfdt_drv 0x0000000000270120 0x80 test/built-in.o 0x0000000000270120 _u_boot_list_2_driver_2_testfdt_drv .u_boot_list_2_driver_2_testprobe_drv 0x00000000002701a0 0x80 test/built-in.o 0x00000000002701a0 _u_boot_list_2_driver_2_testprobe_drv With this, the linker_list no-longer works since items after testfdt1_drv are not at the expected address. Ideally we would have a way to tell gcc not to align structs in this way. It is not clear how we could do this, and in any case it would require us to adjust every struct used by the linker_list feature. One possible fix is to force each separate linker_list to start on the largest possible boundary that can be required by the compiler. However that does not seem to work on x86_64, which uses 16-byte alignment in this case but needs 32-byte alignment. So add a Kconfig option to handle this. Set the default value to 4 so as to avoid changing platforms that don't need it. Update the ll_entry_start() accordingly. Signed-off-by: Simon Glass <[email protected]>
2019-07-24doc: Move existing rst files into api sub-directoryBin Meng
Currently the Sphinx doc only contains API descriptions of several U-Boot subsystems. For future extension, group these existing docs into an API sub-directory. Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>