Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1279725
| From | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file |
| Date | 2015-11-30 10:30 +0100 |
| Message-ID | <qAsWt-1JR-17@gated-at.bofh.it> (permalink) |
| References | <qzmT8-uQ-3@gated-at.bofh.it> <qzmT8-uQ-1@gated-at.bofh.it> <qAcRH-8lW-13@gated-at.bofh.it> <qAoSR-7Gx-5@gated-at.bofh.it> <qAstt-1kv-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2015/11/30 16:51, Namhyung Kim wrote:
> On Mon, Nov 30, 2015 at 01:00:46PM +0800, Wangnan (F) wrote:
>>
>> 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@huawei.com>
>>>> Signed-off-by: He Kuang <hekuang@huawei.com>
>>>> Cc: Alexei Starovoitov <ast@kernel.org>
>>>> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
>>>> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>>>> Cc: Namhyung Kim <namhyung@kernel.org>
>>>> Cc: Zefan Li <lizefan@huawei.com>
>>>> Cc: pi3orama@163.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.
> AFAIK there're two symbol string tables in a ELF file. One for
> section headers (.shstrtab) and another for normal symbols (.strtab).
> And ehdr->e_shstrndx is the index of section header string table so
> your code assumes map names are saved in the section header string
> table, right?
>
> Thanks,
> Namhyung
In case of gcc:
$ echo 'int func() {return 0;}' | gcc -x c -c -o ./temp.o -
$ readelf -h ./temp.o
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 240 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 11
Section header string table index: 8
Let's see what is section 8:
$ readelf -S ./temp.o
...
[ 8] .shstrtab STRTAB 0000000000000000 00000098
0000000000000054 0000000000000000 0 0 1
...
Yes, in this case it is .shstrtab.
However, this is what I found when using llvm:
$ echo 'int func() {return 0;}' | x86_64-oe-linux-clang -x c -c -o
./temp.o -
ELF Header:
Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: REL (Relocatable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 648 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 10
Section header string table index: 1
$ readelf -S ./temp.o
There are 10 section headers, starting at offset 0x288:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .strtab STRTAB 0000000000000000 00000230
0000000000000051 0000000000000000 0 0 1
This time it is strtab.
And here is the content of strtab:
$ readelf -p .strtab ./temp.o
String dump of section '.strtab':
[ 1] .text
[ 7] .comment
[ 10] .bss
[ 15] .note.GNU-stack
[ 25] .rela.eh_frame
[ 34] func
[ 39] .strtab
[ 41] .symtab
[ 49] .data
[ 4f] -
Note that I don't use BPF backend. This is a normal x86 compiling.
So seems it is the default behavior of LLVM.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file Wang Nan <wangnan0@huawei.com> - 2015-11-27 09:50 +0100
[tip:perf/core] tools lib bpf: Extract and collect map names from BPF object file tip-bot for Wang Nan <tipbot@zytor.com> - 2015-11-29 09:00 +0100
Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file Namhyung Kim <namhyung@kernel.org> - 2015-11-29 17:20 +0100
Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-30 06:10 +0100
Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file Namhyung Kim <namhyung@kernel.org> - 2015-11-30 10:00 +0100
Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-30 10:30 +0100
Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file Namhyung Kim <namhyung@gmail.com> - 2015-11-30 10:50 +0100
Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-30 10:50 +0100
[PATCH] tools lib bpf: Fetch map names from correct strtab Wang Nan <wangnan0@huawei.com> - 2015-11-30 11:40 +0100
Re: [PATCH] tools lib bpf: Fetch map names from correct strtab Namhyung Kim <namhyung@kernel.org> - 2015-11-30 12:30 +0100
csiph-web