Support BPF object linking #1942
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dylandreimerink
force-pushed
the
feature/load-linked-elfs
branch
7 times, most recently
from
4520a8c to
c5aba68
Compare
This commit adds test data for ELF linking. `linker1.c` and `linker2.c` contain strong an weak symbols. They are then linked together with `bpftool gen object`. This commit also updates the testdata docker image to include `bpftool`. Signed-off-by: Dylan Reimerink <[email protected]>
You can define programs and functions as `__weak`. This allows you to overwrite the definition of that program when linking multiple ELF files together. When multiple ELF files are linked together the linker will simply combine both sections, so the resulting ELF contains both the original and the new definition. However, the linker will only preserve the symbol of the "winning" definition. Up until now we have made the assumption that the whole section should be translated into the ProgramSpec. However, we now change this to only include the instructions that have a symbol, using the size of the symbol to determine when to stop in case of tailing instructions. Signed-off-by: Dylan Reimerink <[email protected]>
It is possible to define a map as `__weak`. This allows you to link multiple ELF files together assuming the map definitions are compatible. This means you can define logic that operates on a map in multiple compilation units and have it be a single map after linking. When multiple ELF files are linked together the contents of map sections are merged. But only the symbol of the "winning" map is retained. Our existing logic assumed that all of the contents of the map sections were active maps and that it exactly matches the BTF var sec info. This commit changes the logic to use the actual offset and sizes indicated by the symbols and to compare these against the BTF var sec info. Signed-off-by: Dylan Reimerink <[email protected]>
dylandreimerink
force-pushed
the
feature/load-linked-elfs
branch
from
c5aba68 to
3b71af2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Lets add support for ELF object linking, that is loading ELF files that have been linked.
In normal non-eBPF C programs it is very normal to have multiple compilation units (C files that compile to .o files) and then at the end to have a separate linker combine these into an executable. In the eBPF world we typically work with single compilation units which we turn into CollectionSpec's and then Collections.
However, libbpf does offer linker logic which can be used via the bpftool utility. You invoke it like
bpftool gen object out.o in1.o in2.o in3.o ..... In this linking process the contents of the sections are simply appended to each other, and the linker, and the linker keeps only the symbols that "win". The rule being that a strong symbol overwrites a weak symbol, so a strong symbol from in3.o will overwrite a weak symbol from in1.o. If multiple weak symbols are present then the first takes precedence. So a weak symbol in in1.o wins over one in in3.o.So, a practical example is our new testdata added in the PR, this is linker1.o (edited to only show .text symbols):
And here is linker2.o
This is the linked object:
Here you can see, specifically from the second column of the .text dump that both sections are combined. Crucially for the assumptions of the library, is that not the whole contents of the section should be used. We need to collect all symbols for a given section, and only consider the bits of the section indicated by a symbol (offset ; offset+size). The same is also true for maps.
Fixes: #466