Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753302AbbK3J23 (ORCPT ); Mon, 30 Nov 2015 04:28:29 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:6891 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752430AbbK3J21 (ORCPT ); Mon, 30 Nov 2015 04:28:27 -0500 Message-ID: <565C169D.2090402@huawei.com> Date: Mon, 30 Nov 2015 17:27:57 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Namhyung Kim CC: , , , , , , He Kuang , Arnaldo Carvalho de Melo Subject: Re: [PATCH v2 02/13] bpf tools: Extract and collect map names from BPF object file References: <1448614067-197576-1-git-send-email-wangnan0@huawei.com> <1448614067-197576-3-git-send-email-wangnan0@huawei.com> <20151129161434.GE16382@danjae.kornet> <565BD7FE.50405@huawei.com> <20151130085130.GB14252@danjae.kornet> In-Reply-To: <20151130085130.GB14252@danjae.kornet> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.565C16AE.0161,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cf17ce9e4d4c2c1b84694806d685cfe3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6797 Lines: 188 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 >>>> Signed-off-by: He Kuang >>>> Cc: Alexei Starovoitov >>>> Cc: Arnaldo Carvalho de Melo >>>> Cc: Masami Hiramatsu >>>> Cc: Namhyung Kim >>>> Cc: Zefan Li >>>> 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/