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:48:43 +0800
From:	pi3orama <pi3orama@....com>
To:	"Wangnan (F)" <wangnan0@...wei.com>
Cc:	Alexei Starovoitov <ast@...mgrid.com>,
	He Kuang <hekuang@...wei.com>,
	"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

Just for your information:

The buggy DW_AT_name seems to be a problem in assembler.

I built the C file using -S:

$ clang -target bpf -g -c -O2 test.c

Then in resuming test.s, replaced all BPF op by "nop";

Also adjust .file directive;

Then assemble the .s file using as:

$ as -c test.s -o test.o

Then check dwarf info using objdump:

$ objdump --dwarf=info test.o

DW_AT_name looks all correct.

Thank you.


发自我的 iPhone

> 在 2015年7月31日,下午6:18,Wangnan (F) <wangnan0@...wei.com> 写道:
> 
> 
> 
> 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ