[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <565BD7FE.50405@huawei.com>
Date: Mon, 30 Nov 2015 13:00:46 +0800
From: "Wangnan (F)" <wangnan0@...wei.com>
To: Namhyung Kim <namhyung@...nel.org>
CC: <acme@...nel.org>, <ast@...nel.org>,
<linux-kernel@...r.kernel.org>, <masami.hiramatsu.pt@...achi.com>,
<lizefan@...wei.com>, <pi3orama@....com>,
He Kuang <hekuang@...wei.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from
BPF object file
On 2015/11/30 0:14, Namhyung Kim wrote:
> Hi Wang,
>
> On Fri, Nov 27, 2015 at 08:47:36AM +0000, Wang Nan wrote:
>> This patch collects name of maps in BPF object files and saves them into
>> 'maps' field in 'struct bpf_object'. 'bpf_object__get_map_by_name' is
>> introduced to retrive fd and definitions of a map through its name.
>>
>> Signed-off-by: Wang Nan <wangnan0@...wei.com>
>> Signed-off-by: He Kuang <hekuang@...wei.com>
>> Cc: Alexei Starovoitov <ast@...nel.org>
>> Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
>> Cc: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
>> Cc: Namhyung Kim <namhyung@...nel.org>
>> Cc: Zefan Li <lizefan@...wei.com>
>> Cc: pi3orama@....com
>> ---
>> tools/lib/bpf/libbpf.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++---
>> tools/lib/bpf/libbpf.h | 3 +++
>> 2 files changed, 65 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index f509825..a298614 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -165,6 +165,7 @@ struct bpf_program {
>>
>> struct bpf_map {
>> int fd;
>> + char *name;
>> struct bpf_map_def def;
>> void *priv;
>> bpf_map_clear_priv_t clear_priv;
>> @@ -526,12 +527,46 @@ bpf_object__init_maps(struct bpf_object *obj, void *data,
>> return 0;
>> }
>>
>> +static void
>> +bpf_object__init_maps_name(struct bpf_object *obj, int maps_shndx)
>> +{
>> + int i;
>> + Elf_Data *symbols = obj->efile.symbols;
>> +
>> + if (!symbols || maps_shndx < 0)
>> + return;
>> +
>> + for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
>> + GElf_Sym sym;
>> + size_t map_idx;
>> + const char *map_name;
>> +
>> + if (!gelf_getsym(symbols, i, &sym))
>> + continue;
>> + if (sym.st_shndx != maps_shndx)
>> + continue;
>> +
>> + map_name = elf_strptr(obj->efile.elf,
>> + obj->efile.ehdr.e_shstrndx,
>> + sym.st_name);
> It means that each map name is saved in section header string table?
According to elf format specification:
For an symbol table entry, the st_name field "holds an index
into the object file’s symbol string table, which holds the
character representations of the symbol names. If the value
is non-zero, it represents a string table index that gives
the symbol name. Otherwise, the symbol table entry has no
name."
And so called "object file’s symbol string table" is a
section in the object file which index is stored into
ehdr and be loaded during gelf_getehdr(), and its index
would be set to ehdr->e_shstrndx. So I think for each map
its name should be saved in that string table.
>
>> + map_idx = sym.st_value / sizeof(struct bpf_map_def);
>> + if (map_idx >= obj->nr_maps) {
>> + pr_warning("index of map \"%s\" is buggy: %zu > %zu\n",
>> + map_name, map_idx, obj->nr_maps);
>> + continue;
>> + }
>> + obj->maps[map_idx].name = strdup(map_name);
> You need to check the return value.
Will send a patch for it.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists