Re: __builtin_memcpy behavior
Toke Høiland-Jørgensen
"Tristan Mayfield" <mayfieldtristan@...> writes:
Toke, thanks for the quick response!Right, in that case that's probably just because the struct in question is next to some other valid memory (not sure where tracepoints keep their data, but if it's on the stack, for instance, you'll have no problem reading past it). Now that you mention CO-RE, it does actually make sense that theseI'm by no means the leading authority on CO-RE, but I can give answering a shot; hopefully someone will chime in to correct me if I'm wrong :) I don't have control over kernel versions or compilation flags for theYeah, getting all your ducks in a row when compiling can be a bit of an issue. However, I don't think you need anything special from the kernel at compile-time if you just compile your own programs with a vmlinux.h file you generated on a kernel that has been compiled with BTF. I've also been very unclear, and have gotten many different answersWell, you'll need the BTF information of the running kernel. It doesn't *have* to come from /sys/kernel/btf/vmlinux, libbpf will look for it in a few other locations as well: https://github.com/libbpf/libbpf/blob/master/src/btf.c#L4583 Distros have gotten pretty good about enabling BTF in their kernel builds, though, so it's getting increasingly feasible to rely on it. It should certainly be available on RHEL8 (and thus CentOS 8). If that's set, do you also need a vmlinux.h file as well? A coworkerNo, you don't need to ship the vmlinux.h file. That's just a regular header file with an unusual amount of definitions in it, that will be used at compile time. It can be useful to include a copy of it in your source code repository, though, as mentioned above. That's what BCC does, for instance: https://github.com/iovisor/bcc/tree/master/libbpf-tools/x86 An no, it's not 1GB in size. Maybe that size was from before BTF de-duplication got implemented? The one linked above is 2.7M. In addition to that, I've been unclear in the role of BTF in BPFOne common cause for this has been when loading 'tc' programs with iproute2, because the iproute2 loader doesn't understand BTF and will complain about it. That is usually harmless, though, but I agree it's quite annoying. Fortunately, iproute2 has recently gained support for using libbpf for its BPF loading, so hopefully that particular error should go away before too long. Unfortunately I haven't saved any of these errors andYes, the new-style map definitions use BTF. While BTF is ostensibly a type format (i.e., something that describes C data types), Andrii figured out that it is also possible to use it as a general purpose key/value store. You do this by being a bit clever about how you represent your data, which is what the __uint() macro in the above is doing (it's encoding the integer value as the size of an array, which becomes part of the type and thus embedded in the BTF). When loading, libbpf will parse this data back out of the BTF data and use it when creating the map. So you'll need BTF support in your compiler and in libbpf to use this style of map definitions. Am I misunderstanding what BTF is and the role it plays in BPF? OrHmm, no, CO-RE is the specific feature that does relocations of struct fields based on member names. This relies on BTF, but it's not the only thing BTF is used for. The map definition is another, as you discovered, and there are some program types that cannot work without BTF information at all. Also, things like bpftool being able to print out the struct layout of map values is using BTF. So you're certainly right that the BPF ecosystem in general is moving towards using BTF in more and more places. And I guess you're also right that this leads to some cryptic error messages sometimes... :) -Toke
|
|