Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1200548 > unrolled thread

Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4  3/3] bpf: Introduce function for outputing data to perf event He Kuang <hekuang@huawei.com> - 2015-08-05 11:00 +0200
    Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re:  [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2015-08-06 05:50 +0200
      Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re:  [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event "Wangnan (F)" <wangnan0@huawei.com> - 2015-08-06 06:40 +0200
        Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re:  [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2015-08-06 09:00 +0200

#1200548 — Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event

Hi, Alexei

On 2015/7/30 1:13, Alexei Starovoitov wrote:
> On 7/29/15 2:38 AM, He Kuang wrote:
>> Hi, Alexei
>>
>> On 2015/7/28 10:18, Alexei Starovoitov wrote:
>>> On 7/25/15 3:04 AM, He Kuang wrote:
>>>> I noticed that for 64-bit elf format, the reloc sections have
>>>> 'Addend' in the entry, but there's no 'Addend' info in bpf elf
>>>> file(64bit). I think there must be something wrong in the process
>>>> of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the
>>>> AT_name now, DW_AT_LOCATION still missed and need your help.
>>>

Another thing about DW_AT_name, we've already found that the name
string is stored indirectly and needs relocation which is
architecture specific, while the e_machine info in bpf obj file
is "unknown", both objdump and libdw cannot parse DW_AT_name
correctly.

Should we just use a known architeture for bpf object file
instead of "unknown"? If so, we can use the existing relocation
codes in libdw and get DIE name by simply invoking
dwarf_diename(). The drawback of this method is that, e.g. we
use "x86-64" instead, is hard to distinguish bpf obj file with
x86-64 elf file. Do you think this is ok?

Otherwise, for not touching libdw, we should reimplement the
relocation codes already in libdw for bpf elf file with "unknown"
machine info specially in perf. I wonder whether it is worth doing
this and what's your opinion?

Thank you.

>> index directly:
>>
>>    __bpf_trace_output_data(__builtin_dwarf_type(myvar_a), &myvar_a, size);
>>
>
> 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
>
>

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

[toc] | [next] | [standalone]

#1201414 — Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event

On Wed, Aug 05, 2015 at 04:59:01PM +0800, He Kuang wrote:
> Hi, Alexei
> 
> On 2015/7/30 1:13, Alexei Starovoitov wrote:
> >On 7/29/15 2:38 AM, He Kuang wrote:
> >>Hi, Alexei
> >>
> >>On 2015/7/28 10:18, Alexei Starovoitov wrote:
> >>>On 7/25/15 3:04 AM, He Kuang wrote:
> >>>>I noticed that for 64-bit elf format, the reloc sections have
> >>>>'Addend' in the entry, but there's no 'Addend' info in bpf elf
> >>>>file(64bit). I think there must be something wrong in the process
> >>>>of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the
> >>>>AT_name now, DW_AT_LOCATION still missed and need your help.
> >>>
> 
> Another thing about DW_AT_name, we've already found that the name
> string is stored indirectly and needs relocation which is
> architecture specific, while the e_machine info in bpf obj file
> is "unknown", both objdump and libdw cannot parse DW_AT_name
> correctly.
> 
> Should we just use a known architeture for bpf object file
> instead of "unknown"? If so, we can use the existing relocation
> codes in libdw and get DIE name by simply invoking
> dwarf_diename(). The drawback of this method is that, e.g. we
> use "x86-64" instead, is hard to distinguish bpf obj file with
> x86-64 elf file. Do you think this is ok?

The only clean way would be to register bpf as an architecture
with elf standards committee. I have no idea who is doing that and
how much such new e_machine registration may cost.
So far using EM_NONE is a hack to avoid bureaucracy.
Are dwarf relocation processor specific?
Then simple hack to elfutils/libdw to treat EM_NONE as X64
should do the trick, right?
If that indeed works, we can tweak bpf backend to use EM_X86_64,
but then the danger that such .o file will be wrongly
recognized by elf utils. imo it's safer to keep it as EM_NONE
until real number is assigned, but even after it's assigned it
will take time to propagate that value. So for now I would try
to find a solution keeping EM_NONE hack.

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

[toc] | [prev] | [next] | [standalone]

#1201425 — Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event

On 2015/8/6 11:41, Alexei Starovoitov wrote:
> On Wed, Aug 05, 2015 at 04:59:01PM +0800, He Kuang wrote:
>> Hi, Alexei
>>
>> On 2015/7/30 1:13, Alexei Starovoitov wrote:
>>> On 7/29/15 2:38 AM, He Kuang wrote:
>>>> Hi, Alexei
>>>>
>>>> On 2015/7/28 10:18, Alexei Starovoitov wrote:
>>>>> On 7/25/15 3:04 AM, He Kuang wrote:
>>>>>> I noticed that for 64-bit elf format, the reloc sections have
>>>>>> 'Addend' in the entry, but there's no 'Addend' info in bpf elf
>>>>>> file(64bit). I think there must be something wrong in the process
>>>>>> of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the
>>>>>> AT_name now, DW_AT_LOCATION still missed and need your help.
>> Another thing about DW_AT_name, we've already found that the name
>> string is stored indirectly and needs relocation which is
>> architecture specific, while the e_machine info in bpf obj file
>> is "unknown", both objdump and libdw cannot parse DW_AT_name
>> correctly.
>>
>> Should we just use a known architeture for bpf object file
>> instead of "unknown"? If so, we can use the existing relocation
>> codes in libdw and get DIE name by simply invoking
>> dwarf_diename(). The drawback of this method is that, e.g. we
>> use "x86-64" instead, is hard to distinguish bpf obj file with
>> x86-64 elf file. Do you think this is ok?
> The only clean way would be to register bpf as an architecture
> with elf standards committee. I have no idea who is doing that and
> how much such new e_machine registration may cost.
> So far using EM_NONE is a hack to avoid bureaucracy.
> Are dwarf relocation processor specific?
> Then simple hack to elfutils/libdw to treat EM_NONE as X64
> should do the trick, right?
> If that indeed works, we can tweak bpf backend to use EM_X86_64,
> but then the danger that such .o file will be wrongly
> recognized by elf utils. imo it's safer to keep it as EM_NONE
> until real number is assigned, but even after it's assigned it
> will take time to propagate that value. So for now I would try
> to find a solution keeping EM_NONE hack.
>

What about hacking ELF binary in memory?

1. load the object into memory;
2. twist the machine code to EM_X86_64;
3. load it using elf_begin;
4. return the twested elf memory image using libdwfl's find_elf callback.

Then libdw will recognise BPF's object file as a X86_64 object file. If 
required,
relocation sections can also be twisted in this way. Should not very 
hard since
we can only consider one relocation type.

Then let's start thinking how to introduce EM_BPF. We can rely on the 
hacking
until EM_BPF symbol reaches elfutils in perf.

What do you think?

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/

[toc] | [prev] | [next] | [standalone]

#1201476 — Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event

On Thu, Aug 06, 2015 at 12:31:26PM +0800, Wangnan (F) wrote:
> 
> 
> What about hacking ELF binary in memory?
> 
> 1. load the object into memory;
> 2. twist the machine code to EM_X86_64;
> 3. load it using elf_begin;
> 4. return the twested elf memory image using libdwfl's find_elf callback.
> 
> Then libdw will recognise BPF's object file as a X86_64 object file. If
> required,
> relocation sections can also be twisted in this way. Should not very hard
> since
> we can only consider one relocation type.
> 
> Then let's start thinking how to introduce EM_BPF. We can rely on the
> hacking
> until EM_BPF symbol reaches elfutils in perf.
> 
> What do you think?

sounds crazy, but may work. let's try it :)

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web