Changes in Build

e7ac331b - libbpf: Split field iter code into its own file kernel

Thu, 20 Jun 2024 09:17:30 +0000

libbpf: Split field iter code into its own file kernelThis will allow it to be shared with the kernel. No functional change.Suggested-by: Andrii Nakryiko Signed-off-by: Alan Maguire Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240620091733.1967885-4-alan.maguire@oracle.com List of files: /linux-6.15/tools/lib/bpf/Build

19e00c89 - libbpf: Split BTF relocation

Thu, 13 Jun 2024 09:50:08 +0000

libbpf: Split BTF relocationMap distilled base BTF type ids referenced in split BTF and theirreferences to the base BTF passed in, and if the mapping succeeds,reparent the split BTF to the base BTF.Relocation is done by first verifying that distilled base BTFonly consists of named INT, FLOAT, ENUM, FWD, STRUCT andUNION kinds; then we sort these to speed lookups. Once sorted,the base BTF is iterated, and for each relevant kind we checkfor an equivalent in distilled base BTF. When found, themapping from distilled -> base BTF id and string offset is recorded.In establishing mappings, we need to ensure we check STRUCT/UNIONsize when the STRUCT/UNION is embedded in a split BTF STRUCT/UNION,and when duplicate names exist for the same STRUCT/UNION. Otherwisesize is ignored in matching STRUCT/UNIONs.Once all mappings are established, we can update type idsand string offsets in split BTF and reparent it to the new base.Signed-off-by: Alan Maguire Signed-off-by: Andrii Nakryiko Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20240613095014.357981-4-alan.maguire@oracle.com List of files: /linux-6.15/tools/lib/bpf/Build

05f9cdd5 - libbpf: Move feature detection code into its own file

Wed, 24 Jan 2024 02:21:20 +0000

libbpf: Move feature detection code into its own fileIt's quite a lot of well isolated code, so it seems like a goodcandidate to move it out of libbpf.c to reduce its size.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20240124022127.2379740-24-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/Build

d17aff80 - Revert BPF token-related functionality

Tue, 19 Dec 2023 15:37:35 +0000

Revert BPF token-related functionalityThis patch includes the following revert (one conflicting BPF FSpatch and three token patch sets, represented by merge commits): - revert 0f5d5454c723 "Merge branch 'bpf-fs-mount-options-parsing-follow-ups'"; - revert 750e785796bb "bpf: Support uid and gid when mounting bpffs"; - revert 733763285acf "Merge branch 'bpf-token-support-in-libbpf-s-bpf-object'"; - revert c35919dcce28 "Merge branch 'bpf-token-and-bpf-fs-based-delegation'".Link: https://lore.kernel.org/bpf/CAHk-=wg7JuFYwGy=GOMbRCtOL+jwSQsdUaBsRWkDVYbxipbM5A@mail.gmail.comSigned-off-by: Andrii Nakryiko List of files: /linux-6.15/tools/lib/bpf/Build

ab8fc393 - libbpf: move feature detection code into its own file

Wed, 13 Dec 2023 19:08:36 +0000

libbpf: move feature detection code into its own fileIt's quite a lot of well isolated code, so it seems like a goodcandidate to move it out of libbpf.c to reduce its size.Acked-by: John Fastabend Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20231213190842.3844987-5-andrii@kernel.orgSigned-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/Build

5c742725 - libbpf: Move elf_find_func_offset* functions to elf object

Wed, 09 Aug 2023 08:34:20 +0000

libbpf: Move elf_find_func_offset* functions to elf objectAdding new elf object that will contain elf related functions.There's no functional change.Suggested-by: Andrii Nakryiko Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20230809083440.3209381-9-jolsa@kernel.orgSigned-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/Build

1eebcb60 - libbpf: Implement basic zip archive parsing support

Wed, 01 Mar 2023 21:23:06 +0000

libbpf: Implement basic zip archive parsing supportThis change implements support for reading zip archives, includingopening an archive, finding an entry based on its path and name in it,and closing it.The code was copied from https://github.com/iovisor/bcc/pull/4440, whichimplements similar functionality for bcc. The author confirmed that heis fine with this usage and the corresponding relicensing. I adjusted itto adhere to libbpf coding standards.Signed-off-by: Daniel Müller Signed-off-by: Andrii Nakryiko Acked-by: Michał Gregorczyk Link: https://lore.kernel.org/bpf/20230301212308.1839139-2-deso@posteo.net List of files: /linux-6.15/tools/lib/bpf/Build

f3660063 - libbpf: move xsk.{c,h} into selftests/bpf

Mon, 27 Jun 2022 21:15:13 +0000

libbpf: move xsk.{c,h} into selftests/bpfRemove deprecated xsk APIs from libbpf. But given we have selftestsrelying on this, move those files (with minimal adjustments to make themcompilable) under selftests/bpf.We also remove all the removed APIs from libbpf.map, while overallkeeping version inheritance chain, as most APIs are backwardscompatible so there is no need to reassign them as LIBBPF_1.0.0 versions.Cc: Magnus Karlsson Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20220627211527.2245459-2-andrii@kernel.orgSigned-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/Build

2e4913e0 - libbpf: Wire up USDT API and bpf_link integration

Mon, 04 Apr 2022 23:41:57 +0000

libbpf: Wire up USDT API and bpf_link integrationWire up libbpf USDT support APIs without yet implementing all thenitty-gritty details of USDT discovery, spec parsing, and BPF mapinitialization.User-visible user-space API is simple and is conceptually very similarto uprobe API.bpf_program__attach_usdt() API allows to programmatically attach givenBPF program to a USDT, specified through binary path (executable orshared lib), USDT provider and name. Also, just like in uprobe case, PIDfilter is specified (0 - self, -1 - any process, or specific PID).Optionally, USDT cookie value can be specified. Such single APIinvocation will try to discover given USDT in specified binary and willuse (potentially many) BPF uprobes to attach this program in correctlocations.Just like any bpf_program__attach_xxx() APIs, bpf_link is returned thatrepresents this attachment. It is a virtual BPF link that doesn't havedirect kernel object, as it can consist of multiple underlying BPFuprobe links. As such, attachment is not atomic operation and there canbe brief moment when some USDT call sites are attached while others arestill in the process of attaching. This should be taken intoconsideration by user. But bpf_program__attach_usdt() guarantees thatin the case of success all USDT call sites are successfully attached, orall the successfuly attachments will be detached as soon as some USDTcall sites failed to be attached. So, in theory, there could be cases offailed bpf_program__attach_usdt() call which did trigger few USDTprogram invocations. This is unavoidable due to multi-uprobe nature ofUSDT and has to be handled by user, if it's important to create anillusion of atomicity.USDT BPF programs themselves are marked in BPF source code as eitherSEC("usdt"), in which case they won't be auto-attached throughskeleton's __attach() method, or it can have a full definition,which follows the spirit of fully-specified uprobes:SEC("usdt/::"). In the latter case skeleton'sattach method will attempt auto-attachment. Similarly, genericbpf_program__attach() will have enought information to go off of forparameterless attachment.USDT BPF programs are actually uprobes, and as such for kernel they aremarked as BPF_PROG_TYPE_KPROBE.Another part of this patch is USDT-related feature probing: - BPF cookie support detection from user-space; - detection of kernel support for auto-refcounting of USDT semaphore.The latter is optional. If kernel doesn't support such feature and USDTdoesn't rely on USDT semaphores, no error is returned. But if libbpfdetects that USDT requires setting semaphores and kernel doesn't supportthis, libbpf errors out with explicit pr_warn() message. Libbpf doesn'tsupport poking process's memory directly to increment semaphore value,like BCC does on legacy kernels, due to inherent raciness and danger ofsuch process memory manipulation. Libbpf let's kernel take care of thisproperly or gives up.Logistically, all the extra USDT-related infrastructure of libbpf is putinto a separate usdt.c file and abstracted behind struct usdt_manager.Each bpf_object has lazily-initialized usdt_manager pointer, which isonly instantiated if USDT programs are attempted to be attached. ClosingBPF object frees up usdt_manager resources. usdt_manager keeps track ofUSDT spec ID assignment and few other small things.Subsequent patches will fill out remaining missing pieces of USDTinitialization and setup logic.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Reviewed-by: Alan Maguire Link: https://lore.kernel.org/bpf/20220404234202.331384-3-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/Build

b0588390 - libbpf: Split CO-RE logic into relo_core.c.

Wed, 21 Jul 2021 00:08:22 +0000

libbpf: Split CO-RE logic into relo_core.c.Move CO-RE logic into separate file.The internal interface between libbpf and CO-RE is throughbpf_core_apply_relo_insn() function and few structs defined in relo_core.h.Signed-off-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210721000822.40958-5-alexei.starovoitov@gmail.com List of files: /linux-6.15/tools/lib/bpf/Build

67234743 - libbpf: Generate loader program out of BPF ELF file.

Fri, 14 May 2021 00:36:16 +0000

libbpf: Generate loader program out of BPF ELF file.The BPF program loading process performed by libbpf is quite complexand consists of the following steps:"open" phase:- parse elf file and remember relocations, sections- collect externs and ksyms including their btf_ids in prog's BTF- patch BTF datasec (since llvm couldn't do it)- init maps (old style map_def, BTF based, global data map, kconfig map)- collect relocations against progs and maps"load" phase:- probe kernel features- load vmlinux BTF- resolve externs (kconfig and ksym)- load program BTF- init struct_ops- create maps- apply CO-RE relocations- patch ld_imm64 insns with src_reg=PSEUDO_MAP, PSEUDO_MAP_VALUE, PSEUDO_BTF_ID- reposition subprograms and adjust call insns- sanitize and load progsDuring this process libbpf does sys_bpf() calls to load BTF, create maps,populate maps and finally load programs.Instead of actually doing the syscalls generate a trace of what libbpfwould have done and represent it as the "loader program".The "loader program" consists of single map with:- union bpf_attr(s)- BTF bytes- map value bytes- insns bytesand single bpf program that passes bpf_attr(s) and data into bpf_sys_bpf() helper.Executing such "loader program" via bpf_prog_test_run() command willreplay the sequence of syscalls that libbpf would have done which will resultthe same maps created and programs loaded as specified in the elf file.The "loader program" removes libelf and majority of libbpf dependency fromprogram loading process.kconfig, typeless ksym, struct_ops and CO-RE are not supported yet.The order of relocate_data and relocate_calls had to change, so thatbpf_gen__prog_load() can see all relocations for a given program withcorrect insn_idx-es.Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210514003623.28033-15-alexei.starovoitov@gmail.com List of files: /linux-6.15/tools/lib/bpf/Build

faf6ed32 - libbpf: Add BPF static linker APIs

Thu, 18 Mar 2021 19:40:30 +0000

libbpf: Add BPF static linker APIsIntroduce BPF static linker APIs to libbpf. BPF static linker allows toperform static linking of multiple BPF object files into a single combinedresulting object file, preserving all the BPF programs, maps, globalvariables, etc.Data sections (.bss, .data, .rodata, .maps, maps, etc) with the same name areconcatenated together. Similarly, code sections are also concatenated. All thesymbols and ELF relocations are also concatenated in their respective ELFsections and are adjusted accordingly to the new object file layout.Static variables and functions are handled correctly as well, adjusting BPFinstructions offsets to reflect new variable/function offset within thecombined ELF section. Such relocations are referencing STT_SECTION symbols andthat stays intact.Data sections in different files can have different alignment requirements, sothat is taken care of as well, adjusting sizes and offsets as necessary tosatisfy both old and new alignment requirements.DWARF data sections are stripped out, currently. As well as LLLVM_ADDRSIGsection, which is ignored by libbpf in bpf_object__open() anyways. So, ina way, BPF static linker is an analogue to `llvm-strip -g`, which is a prettynice property, especially if resulting .o file is then used to generate BPFskeleton.Original string sections are ignored and instead we construct our own set ofunique strings using libbpf-internal `struct strset` API.To reduce the size of the patch, all the .BTF and .BTF.ext processing wasmoved into a separate patch.The high-level API consists of just 4 functions: - bpf_linker__new() creates an instance of BPF static linker. It accepts output filename and (currently empty) options struct; - bpf_linker__add_file() takes input filename and appends it to the already processed ELF data; it can be called multiple times, one for each BPF ELF object file that needs to be linked in; - bpf_linker__finalize() needs to be called to dump final ELF contents into the output file, specified when bpf_linker was created; after bpf_linker__finalize() is called, no more bpf_linker__add_file() and bpf_linker__finalize() calls are allowed, they will return error; - regardless of whether bpf_linker__finalize() was called or not, bpf_linker__free() will free up all the used resources.Currently, BPF static linker doesn't resolve cross-object file references(extern variables and/or functions). This will be added in the follow up patchset.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210318194036.3521577-7-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/Build

90d76d3e - libbpf: Extract internal set-of-strings datastructure APIs

Thu, 18 Mar 2021 19:40:28 +0000

libbpf: Extract internal set-of-strings datastructure APIsExtract BTF logic for maintaining a set of strings data structure, used forBTF strings section construction in writable mode, into separate re-usableAPI. This data structure is going to be used by bpf_linker to maintains ELFSTRTAB section, which has the same layout as BTF strings section.Suggested-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210318194036.3521577-5-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/Build

bf99c936 - libbpf: Add BPF ring buffer support

Fri, 29 May 2020 07:54:21 +0000

libbpf: Add BPF ring buffer supportDeclaring and instantiating BPF ring buffer doesn't require any changes tolibbpf, as it's just another type of maps. So using existing BTF-defined mapssyntax with __uint(type, BPF_MAP_TYPE_RINGBUF) and __uint(max_elements,) is all that's necessary to create and use BPF ring buffer.This patch adds BPF ring buffer consumer to libbpf. It is very similar toperf_buffer implementation in terms of API, but also attempts to fix someminor problems and inconveniences with existing perf_buffer API.ring_buffer support both single ring buffer use case (with just usingring_buffer__new()), as well as allows to add more ring buffers, each with itsown callback and context. This allows to efficiently poll and consumemultiple, potentially completely independent, ring buffers, using singleepoll instance.The latter is actually a problem in practice for applicationsthat are using multiple sets of perf buffers. They have to create multipleinstances for struct perf_buffer and poll them independently or in a loop,each approach having its own problems (e.g., inability to use a common polltimeout). struct ring_buffer eliminates this problem by aggregating manyindependent ring buffer instances under the single "ring buffer manager".Second, perf_buffer's callback can't return error, so applications that needto stop polling due to error in data or data signalling the end, have to useextra mechanisms to signal that polling has to stop. ring_buffer's callbackcan return error, which will be passed through back to user code and can beacted upon appropariately.Two APIs allow to consume ring buffer data: - ring_buffer__poll(), which will wait for data availability notification and will consume data only from reported ring buffer(s); this API allows to efficiently use resources by reading data only when it becomes available; - ring_buffer__consume(), will attempt to read new records regardless of data availablity notification sub-system. This API is useful for cases when lowest latency is required, in expense of burning CPU resources.Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200529075424.3139988-3-andriin@fb.comSigned-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/Build

351131b5 - libbpf: add btf_dump API for BTF-to-C conversion

Fri, 24 May 2019 18:59:03 +0000

libbpf: add btf_dump API for BTF-to-C conversionBTF contains enough type information to allow generating validcompilable C header w/ correct layout of structs/unions and all thetypedef/enum definitions. This patch adds a new "object" - btf_dump tofacilitate dumping BTF as valid C. btf_dump__dump_type() is the main APIwhich takes care of dumping out (through user-provided printf-likecallback function) C definitions for given type ID and it's requireddependencies. This allows for not just dumping out entirety of BTF types,but also selective filtering based on user-provided criterias w/ minimalset of dependent types.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/Build

e3b92422 - libbpf: add resizable non-thread safe internal hashmap

Fri, 24 May 2019 18:59:00 +0000

libbpf: add resizable non-thread safe internal hashmapThere is a need for fast point lookups inside libbpf for multiple usecases (e.g., name resolution for BTF-to-C conversion, by-name lookups inBTF for upcoming BPF CO-RE relocation support, etc). This patchimplements simple resizable non-thread safe hashmap using single linkedlist chains.Four different insert strategies are supported: - HASHMAP_ADD - only add key/value if key doesn't exist yet; - HASHMAP_SET - add key/value pair if key doesn't exist yet; otherwise, update value; - HASHMAP_UPDATE - update value, if key already exists; otherwise, do nothing and return -ENOENT; - HASHMAP_APPEND - always add key/value pair, even if key already exists. This turns hashmap into a multimap by allowing multiple values to be associated with the same key. Most useful read API for such hashmap is hashmap__for_each_key_entry() iteration. If hashmap__find() is still used, it will return last inserted key/value entry (first in a bucket chain).For HASHMAP_SET and HASHMAP_UPDATE, old key/value pair is returned, sothat calling code can handle proper memory management, if necessary.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/Build

1cad0788 - libbpf: add support for using AF_XDP sockets

Thu, 21 Feb 2019 09:21:26 +0000

libbpf: add support for using AF_XDP socketsThis commit adds AF_XDP support to libbpf. The main reason for this isto facilitate writing applications that use AF_XDP by offeringhigher-level APIs that hide many of the details of the AF_XDPuapi. This is in the same vein as libbpf facilitates XDP adoption byoffering easy-to-use higher level interfaces of XDPfunctionality. Hopefully this will facilitate adoption of AF_XDP, makeapplications using it simpler and smaller, and finally also make itpossible for applications to benefit from optimizations in the AF_XDPuser space access code. Previously, people just copied and pasted thecode from the sample application into their application, which is notdesirable.The interface is composed of two parts:* Low-level access interface to the four rings and the packet* High-level control plane interface for creating and setting up umems and af_xdp sockets as well as a simple XDP program.Tested-by: Björn Töpel Signed-off-by: Magnus Karlsson Signed-off-by: Daniel Borkmann List of files: /linux-6.15/tools/lib/bpf/Build

1bf4b058 - tools: bpftool: add probes for eBPF program types

Thu, 17 Jan 2019 15:27:53 +0000

tools: bpftool: add probes for eBPF program typesIntroduce probes for supported BPF program types in libbpf, and call itfrom bpftool to test what types are available on the system. The probesimply consists in loading a very basic program of that type and see ifthe verifier complains or not.Sample output: # bpftool feature probe kernel ... Scanning eBPF program types... eBPF program_type socket_filter is available eBPF program_type kprobe is available eBPF program_type sched_cls is available ... # bpftool --json --pretty feature probe kernel { ... "program_types": { "have_socket_filter_prog_type": true, "have_kprobe_prog_type": true, "have_sched_cls_prog_type": true, ... } }v5:- In libbpf.map, move global symbol to a new LIBBPF_0.0.2 section.- Rename (non-API function) prog_load() as probe_load().v3:- Get kernel version for checking kprobes availability from libbpf instead of from bpftool. Do not pass kernel_version as an argument when calling libbpf probes.- Use a switch with all enum values for setting specific program parameters just before probing, so that gcc complains at compile time (-Wswitch-enum) if new prog types were added to the kernel but libbpf was not updated.- Add a comment in libbpf.h about setrlimit() usage to allow many consecutive probe attempts.v2:- Move probes from bpftool to libbpf.- Remove C-style macros output from this patch.Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Reviewed-by: Stanislav Fomichev Signed-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/Build

b053b439 - bpf: libbpf: bpftool: Print bpf_line_info during prog dump

Sat, 08 Dec 2018 00:42:32 +0000

bpf: libbpf: bpftool: Print bpf_line_info during prog dumpThis patch adds print bpf_line_info function in 'prog dump jitted'and 'prog dump xlated':[root@arch-fb-vm1 bpf]# ~/devshare/fb-kernel/linux/tools/bpf/bpftool/bpftool prog dump jited pinned /sys/fs/bpf/test_btf_haskv[...]int test_long_fname_2(struct dummy_tracepoint_args * arg):bpf_prog_44a040bf25481309_test_long_fname_2:; static int test_long_fname_2(struct dummy_tracepoint_args *arg) 0: push %rbp 1: mov %rsp,%rbp 4: sub $0x30,%rsp b: sub $0x28,%rbp f: mov %rbx,0x0(%rbp) 13: mov %r13,0x8(%rbp) 17: mov %r14,0x10(%rbp) 1b: mov %r15,0x18(%rbp) 1f: xor %eax,%eax 21: mov %rax,0x20(%rbp) 25: xor %esi,%esi; int key = 0; 27: mov %esi,-0x4(%rbp); if (!arg->sock) 2a: mov 0x8(%rdi),%rdi; if (!arg->sock) 2e: cmp $0x0,%rdi 32: je 0x0000000000000070 34: mov %rbp,%rsi; counts = bpf_map_lookup_elem(&btf_map, &key); 37: add $0xfffffffffffffffc,%rsi 3b: movabs $0xffff8881139d7480,%rdi 45: add $0x110,%rdi 4c: mov 0x0(%rsi),%eax 4f: cmp $0x4,%rax 53: jae 0x000000000000005e 55: shl $0x3,%rax 59: add %rdi,%rax 5c: jmp 0x0000000000000060 5e: xor %eax,%eax; if (!counts) 60: cmp $0x0,%rax 64: je 0x0000000000000070; counts->v6++; 66: mov 0x4(%rax),%edi 69: add $0x1,%rdi 6d: mov %edi,0x4(%rax) 70: mov 0x0(%rbp),%rbx 74: mov 0x8(%rbp),%r13 78: mov 0x10(%rbp),%r14 7c: mov 0x18(%rbp),%r15 80: add $0x28,%rbp 84: leaveq 85: retq[...]With linum:[root@arch-fb-vm1 bpf]# ~/devshare/fb-kernel/linux/tools/bpf/bpftool/bpftool prog dump jited pinned /sys/fs/bpf/test_btf_haskv linumint _dummy_tracepoint(struct dummy_tracepoint_args * arg):bpf_prog_b07ccb89267cf242__dummy_tracepoint:; return test_long_fname_1(arg); [file:/data/users/kafai/fb-kernel/linux/tools/testing/selftests/bpf/test_btf_haskv.c line_num:54 line_col:9] 0: push %rbp 1: mov %rsp,%rbp 4: sub $0x28,%rsp b: sub $0x28,%rbp f: mov %rbx,0x0(%rbp) 13: mov %r13,0x8(%rbp) 17: mov %r14,0x10(%rbp) 1b: mov %r15,0x18(%rbp) 1f: xor %eax,%eax 21: mov %rax,0x20(%rbp) 25: callq 0x000000000000851e; return test_long_fname_1(arg); [file:/data/users/kafai/fb-kernel/linux/tools/testing/selftests/bpf/test_btf_haskv.c line_num:54 line_col:2] 2a: xor %eax,%eax 2c: mov 0x0(%rbp),%rbx 30: mov 0x8(%rbp),%r13 34: mov 0x10(%rbp),%r14 38: mov 0x18(%rbp),%r15 3c: add $0x28,%rbp 40: leaveq 41: retq[...]Signed-off-by: Martin KaFai Lau Acked-by: Yonghong Song Signed-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/Build

6d41907c - tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE systems

Fri, 14 Sep 2018 19:47:14 +0000

tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE systemsSame problem that got fixed in a similar fashion in tools/perf/ inc8b5f2c96d1b ("tools: Introduce str_error_r()"), fix it in the sameway, licensing needs to be sorted out to libbpf to use libapi, so,for this simple case, just get the same wrapper in tools/lib/bpf.This makes libbpf and its users (bpftool, selftests, perf) to buildagain in Alpine Linux 3.[45678] and edge.Acked-by: Alexei Starovoitov Cc: Adrian Hunter Cc: Daniel Borkmann Cc: David Ahern Cc: Hendrik Brueckner Cc: Jakub Kicinski Cc: Jiri Olsa Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Quentin Monnet Cc: Thomas Richter Cc: Wang Nan Cc: Yonghong Song Fixes: 1ce6a9fc1549 ("bpf: fix build error in libbpf with EXTRA_CFLAGS="-Wp, -D_FORTIFY_SOURCE=2 -O2"")Link: https://lkml.kernel.org/r/20180917151636.GA21790@kernel.orgSigned-off-by: Arnaldo Carvalho de Melo List of files: /linux-6.15/tools/lib/bpf/Build