linux-kernel - Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event

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]

Date:	Fri, 31 Jul 2015 18:18:50 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Alexei Starovoitov <ast@...mgrid.com>,
	He Kuang <hekuang@...wei.com>, pi3orama <pi3orama@....com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function
 for outputing data to perf event



On 2015/7/30 1:13, Alexei Starovoitov wrote:

[SNIP]
> probably both A and B won't really work when programs get bigger
> and optimizations will start moving lines around.
> the builtin_dwarf_type idea is actually quite interesting.
> Potentially that builtin can stringify type name and later we can
> search it in dwarf. Please take a look how to add such builtin.
> There are few similar builtins that deal with exception handling
> and need type info. May be they can be reused. Like:
> int_eh_typeid_for and int_eh_dwarf_cfa
>

Hi Alexei,

I have tested int_eh_dwarf_cfa and int_eh_typeid_for.

By implementing ISD::FRAMEADDR support in LLVM BPF backend users are 
allowed to
fetch frame address R11. __builtin_frame_addr(0) and __builtin_dwarf_cfa()
will be enabled.

By emitting llvm.eh_typeid_for in clang we can utilize it go generate an 
unique
ID from a pointer of user defined type. However, we can't use pointer of 
local
variables.

I attach a sample program and the resuling asm output at the bottom of 
this mail.

Looks like llvm.eh_typeid_for meets our goal further. However, currently 
it is
still ugly:

1. llvm.eh_typeid_for can be used on global variables only. So for each 
output
    structure we have to define a global varable.

2. We still need to find a way to connect the fetchd typeid with DWARF info.
    Inserting that ID into DWARF may workable?

    However with the newest llvm + clang the DWARF info is still incorrect:

$ objdump  --dwarf=info ./out.o
...
  <1><3f>: Abbrev Number: 3 (DW_TAG_structure_type)
     <40>   DW_AT_name        : (indirect string, offset: 0x0): clang 
version 3.8.0 (http://llvm.org/git/clang.git 
f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git 
c8ccd78d31d4949fa1c14e954ccb06253e18cf37)
     <44>   DW_AT_byte_size   : 8
     <45>   DW_AT_decl_file   : 1
     <46>   DW_AT_decl_line   : 4
  <2><47>: Abbrev Number: 4 (DW_TAG_member)
     <48>   DW_AT_name        : (indirect string, offset: 0x0): clang 
version 3.8.0 (http://llvm.org/git/clang.git 
f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git 
c8ccd78d31d4949fa1c14e954ccb06253e18cf37)
     <4c>   DW_AT_type        : <0x60>
     <50>   DW_AT_decl_file   : 1
     <51>   DW_AT_decl_line   : 5
     <52>   DW_AT_data_member_location: 0
  <2><53>: Abbrev Number: 4 (DW_TAG_member)
     <54>   DW_AT_name        : (indirect string, offset: 0x0): clang 
version 3.8.0 (http://llvm.org/git/clang.git 
f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git 
c8ccd78d31d4949fa1c14e954ccb06253e18cf37)
     <58>   DW_AT_type        : <0x60>
     <5c>   DW_AT_decl_file   : 1
     <5d>   DW_AT_decl_line   : 6
     <5e>   DW_AT_data_member_location: 4
...

The DW_AT_name is missing.

I'll post 2 LLVM patches by replying this mail. Please have a look and 
help me
send them to LLVM if you think my code is correct.

Following is the sample code and resuling ASM:

========================================================

static int (*test_func)(unsigned long) = (void *) 0x1234;

struct my_str {
         int x;
         int y;
};
struct my_str __str_my_str;

struct my_str2 {
         int x;
         int y;
         int z;
};
struct my_str2 __str_my_str2;

int func(int *ctx)
{
         struct my_str var_a;
         struct my_str2 var_b;
         test_func((void*)&var_a - __builtin_dwarf_cfa());
         test_func(__builtin_bpf_typeid(&__str_my_str));
         test_func(__builtin_bpf_typeid(&__str_my_str2));
         return 0;
}

==================== the resuling asm code =============

         .text
         .globl  func
         .align  8
func:                                   # @func
# BB#0:                                 # %entry
         mov     r1, r10
         addi    r1, -8
         sub     r1, r11
         call    4660
         mov     r1, 1
         call    4660
         mov     r1, 2
         call    4660
         mov     r0, 0
         ret

         .comm   __str_my_str,8,4        # @__str_my_str
         .comm   __str_my_str2,12,4      # @__str_my_str2


--
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/