lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180612203124.GB22039@kernel.org>
Date:   Tue, 12 Jun 2018 17:31:24 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Martin KaFai Lau <kafai@...com>
Cc:     netdev@...r.kernel.org, Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>, kernel-team@...com,
        Wang Nan <wangnan0@...wei.com>, Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH bpf-next v5 00/10] BTF: BPF Type Format

Em Thu, Jun 07, 2018 at 01:07:01PM -0700, Martin KaFai Lau escreveu:
> On Thu, Jun 07, 2018 at 04:30:29PM -0300, Arnaldo Carvalho de Melo wrote:
> > So this must be available in a newer llvm version? Which one?

> I should have put in the details in my last email or
> in the commit message, my bad.
 
> 1. The tools/testing/selftests/bpf/Makefile has the CLANG_FLAGS and
>    LLC_FLAGS needed to compile the bpf prog.  It requires a new
>    "-mattr=dwarf" llc option which was added to the future
>    llvm 7.0.
 
>    Hence, I have been using the llvm's master in github which
>    also has the llvm-objcopy.
 
> 2. The kernel's btf part only focus on the BPF map.
>    Hence, the testing bpf program should have the map's key
>    and map's value.  e.g. tools/testing/selftests/bpf/test_btf_haskv.c

So, with llvm and clang HEAD I get:

[root@...et bpf]# pahole -J hello.o
[root@...et bpf]# file hello.o
hello.o: ELF 64-bit LSB relocatable, *unknown arch 0xf7* version 1 (SYSV), with debug_info, not stripped
[root@...et bpf]# llvm-readelf -s hello.o
There are 26 section headers, starting at offset 0xe30:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        0000000000000000 000040 000000 00  AX  0   0  4
  [ 2] syscalls:sys_enter_openat PROGBITS 0000000000000000 000040 000088 00  AX  0   0  8
  [ 3] license           PROGBITS        0000000000000000 0000c8 000004 00  WA  0   0  1
  [ 4] version           PROGBITS        0000000000000000 0000cc 000004 00  WA  0   0  4
  [ 5] maps              PROGBITS        0000000000000000 0000d0 000010 00  WA  0   0  4
  [ 6] .rodata.str1.1    PROGBITS        0000000000000000 0000e0 00000e 01 AMS  0   0  1
  [ 7] .debug_str        PROGBITS        0000000000000000 0000ee 00010e 01  MS  0   0  1
  [ 8] .debug_loc        PROGBITS        0000000000000000 0001fc 000023 00      0   0  1
  [ 9] .debug_abbrev     PROGBITS        0000000000000000 00021f 0000e3 00      0   0  1
  [10] .debug_info       PROGBITS        0000000000000000 000302 00015e 00      0   0  1
  [11] .debug_ranges     PROGBITS        0000000000000000 000460 000030 00      0   0  1
  [12] .debug_macinfo    PROGBITS        0000000000000000 000490 000001 00      0   0  1
  [13] .debug_pubnames   PROGBITS        0000000000000000 000491 00006e 00      0   0  1
  [14] .debug_pubtypes   PROGBITS        0000000000000000 0004ff 00005a 00      0   0  1
  [15] .debug_frame      PROGBITS        0000000000000000 000560 000028 00      0   0  8
  [16] .debug_line       PROGBITS        0000000000000000 000588 00006e 00      0   0  1
  [17] .symtab           SYMTAB          0000000000000000 0005f8 000318 18     24  29  8
  [18] .relsyscalls:sys_enter_openat REL 0000000000000000 000910 000010 10     17   2  8
  [19] .rel.debug_info   REL             0000000000000000 000920 0001e0 10     17  10  8
  [20] .rel.debug_pubnames REL           0000000000000000 000b00 000010 10     17  13  8
  [21] .rel.debug_pubtypes REL           0000000000000000 000b10 000010 10     17  14  8
  [22] .rel.debug_frame  REL             0000000000000000 000b20 000020 10     17  15  8
  [23] .rel.debug_line   REL             0000000000000000 000b40 000010 10     17  16  8
  [24] .strtab           STRTAB          0000000000000000 000b50 00018e 00      0   0  1
  [25] .BTF              PROGBITS        0000000000000000 000cde 00014e 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)
[root@...et bpf]# 
[root@...et bpf]# pahole hello.o
struct clang version 5.0.1 (tags/RELEASE_501/final) {
	clang version 5.0.1 (tags/RELEASE_501/final) clang version 5.0.1 (tags/RELEASE_501/final); /*     0     4 */
	clang version 5.0.1 (tags/RELEASE_501/final) clang version 5.0.1 (tags/RELEASE_501/final); /*     4     4 */
	clang version 5.0.1 (tags/RELEASE_501/final) clang version 5.0.1 (tags/RELEASE_501/final); /*     8     4 */
	clang version 5.0.1 (tags/RELEASE_501/final) clang version 5.0.1 (tags/RELEASE_501/final); /*    12     4 */

	/* size: 16, cachelines: 1, members: 4 */
	/* last cacheline: 16 bytes */
};
[root@...et bpf]# 


Ok, I guess I saw this case in the llvm/clang git logs, so this one was
generated with the older clang, will regenerate and add that "-mattr=dwarf"
part.

- Arnaldo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ