public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org, Wang Nan <wangnan0@huawei.com>,
	Brendan Gregg <brendan.d.gregg@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	David Ahern <dsahern@gmail.com>, He Kuang <hekuang@huawei.com>,
	Jiri Olsa <jolsa@kernel.org>, Kaixu Xia <xiakaixu@huawei.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Zefan Li <lizefan@huawei.com>,
	pi3orama@163.com, Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: [PATCH 09/24] bpf tools: Collect symbol table from SHT_SYMTAB section
Date: Fri,  7 Aug 2015 11:50:17 -0300	[thread overview]
Message-ID: <1438959032-8637-10-git-send-email-acme@kernel.org> (raw)
In-Reply-To: <1438959032-8637-1-git-send-email-acme@kernel.org>

From: Wang Nan <wangnan0@huawei.com>

This patch collects symbols section. This section is useful when linking
BPF maps.

What 'bpf_map_xxx()' functions actually require are map's file
descriptors (and the internal verifier converts fds into pointers to
'struct bpf_map'), which we don't know when compiling. Therefore, we
should make compiler generate a 'ldr_64 r1, <imm>' instruction, and
fill the 'imm' field with the actual file descriptor when loading in
libbpf.

BPF programs should be written in this way:

 struct bpf_map_def SEC("maps") my_map = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(unsigned long),
    .value_size = sizeof(unsigned long),
    .max_entries = 1000000,
 };

 SEC("my_func=sys_write")
 int my_func(void *ctx)
 {
     ...
     bpf_map_update_elem(&my_map, &key, &value, BPF_ANY);
     ...
 }

Compiler should convert '&my_map' into a 'ldr_64, r1, <imm>'
instruction, where imm should be the address of 'my_map'. According to
the address, libbpf knows which map it actually referenced, and then
fills the imm field with the 'fd' of that map created by it.

However, since we never really 'link' the object file, the imm field is
only a record in relocation section. Therefore libbpf should do the
relocation:

 1. In relocation section (type == SHT_REL), positions of each such
    'ldr_64' instruction are recorded with a reference of an entry in
    symbol table (SHT_SYMTAB);

 2. From records in symbol table we can find the indics of map
    variables.

Libbpf first record SHT_SYMTAB and positions of each instruction which
required bu such operation. Then create file descriptor. Finally, after
map creation complete, replace the imm field.

This is the first patch of BPF map related stuff. It records SHT_SYMTAB
into object's efile field for further use.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kaixu Xia <xiakaixu@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1435716878-189507-12-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/lib/bpf/libbpf.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 87f5054a9efb..9b016c086867 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -94,6 +94,7 @@ struct bpf_object {
 		size_t obj_buf_sz;
 		Elf *elf;
 		GElf_Ehdr ehdr;
+		Elf_Data *symbols;
 	} efile;
 	char path[];
 };
@@ -135,6 +136,7 @@ static void bpf_object__elf_finish(struct bpf_object *obj)
 		elf_end(obj->efile.elf);
 		obj->efile.elf = NULL;
 	}
+	obj->efile.symbols = NULL;
 	zclose(obj->efile.fd);
 	obj->efile.obj_buf = NULL;
 	obj->efile.obj_buf_sz = 0;
@@ -333,6 +335,14 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
 		else if (strcmp(name, "maps") == 0)
 			err = bpf_object__init_maps(obj, data->d_buf,
 						    data->d_size);
+		else if (sh.sh_type == SHT_SYMTAB) {
+			if (obj->efile.symbols) {
+				pr_warning("bpf: multiple SYMTAB in %s\n",
+					   obj->path);
+				err = -EEXIST;
+			} else
+				obj->efile.symbols = data;
+		}
 		if (err)
 			goto out;
 	}
-- 
2.1.0


  parent reply	other threads:[~2015-08-07 14:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07 14:50 [GIT PULL 00/24] perf/ebpf lib + llvm/clang building infrastructure Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 01/24] bpf tools: Introduce 'bpf' library and add bpf feature check Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 02/24] bpf tools: Allow caller to set printing function Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 03/24] bpf tools: Open eBPF object file and do basic validation Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 04/24] bpf tools: Read eBPF object from buffer Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 05/24] bpf tools: Check endianness and make libbpf fail early Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 06/24] bpf tools: Iterate over ELF sections to collect information Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 07/24] bpf tools: Collect version and license from ELF sections Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 08/24] bpf tools: Collect map definitions from 'maps' section Arnaldo Carvalho de Melo
2015-08-07 14:50 ` Arnaldo Carvalho de Melo [this message]
2015-08-07 14:50 ` [PATCH 10/24] bpf tools: Collect eBPF programs from their own sections Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 11/24] bpf tools: Collect relocation sections from SHT_REL sections Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 12/24] bpf tools: Record map accessing instructions for each program Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 13/24] bpf tools: Add bpf.c/h for common bpf operations Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 14/24] bpf tools: Create eBPF maps defined in an object file Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 15/24] bpf tools: Relocate eBPF programs Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 16/24] bpf tools: Introduce bpf_load_program() to bpf.c Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 17/24] bpf tools: Load eBPF programs in object files into kernel Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 18/24] bpf tools: Introduce accessors for struct bpf_program Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 19/24] bpf tools: Link all bpf objects onto a list Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 20/24] perf tools: Introduce llvm config options Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 21/24] perf tools: Call clang to compile C source to object code Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 22/24] perf tools: Auto detecting kernel build directory Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 23/24] perf tools: Auto detecting kernel include options Arnaldo Carvalho de Melo
2015-08-07 14:50 ` [PATCH 24/24] perf tests: Add LLVM test for eBPF on-the-fly compiling Arnaldo Carvalho de Melo
2015-08-08  8:06 ` [GIT PULL 00/24] perf/ebpf lib + llvm/clang building infrastructure Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1438959032-8637-10-git-send-email-acme@kernel.org \
    --to=acme@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=brendan.d.gregg@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=hekuang@huawei.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=pi3orama@163.com \
    --cc=wangnan0@huawei.com \
    --cc=xiakaixu@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox