[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <96f9ebed-81f1-837b-7448-62aad4ebbd69@iogearbox.net>
Date: Fri, 9 Feb 2018 12:50:22 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: netdev@...r.kernel.org, Daniel Borkmann <borkmann@...earbox.net>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
wangnan0@...wei.com, jakub.kicinski@...ronome.com, joe@....org,
acme@...hat.com, eric@...it.org, yhs@...com
Subject: Re: [bpf-next V3 PATCH 0/5] tools/libbpf improvements and selftests
On 02/09/2018 09:18 AM, Jesper Dangaard Brouer wrote:
> On Fri, 9 Feb 2018 02:32:27 +0100
> Daniel Borkmann <daniel@...earbox.net> wrote:
>
>> On 02/08/2018 12:48 PM, Jesper Dangaard Brouer wrote:
>>> While playing with using libbpf for the Suricata project, we had
>>> issues LLVM >= 4.0.1 generating ELF files that could not be loaded
>>> with libbpf (tools/lib/bpf/).
>>>
>>> During the troubleshooting phase, I wrote a test program and improved
>>> the debugging output in libbpf. I turned this into a selftests
>>> program, and it also serves as a code example for libbpf in itself.
>>>
>>> I discovered that there are at least three ELF load issues with
>>> libbpf. I left them as TODO comments in (tools/testing/selftests/bpf)
>>> test_libbpf.sh. I've only fixed the load issue with eh_frames, and
>>> other types of relo-section that does not have exec flags. We can
>>> work on the other issues later.
>>
>> Applied it to bpf tree, thanks Jesper!
>
> Thank you for applying this the 'bpf' tree! -- appreciate it!
Btw, if you have a chance to send a small doc update for the
Documentation/bpf/bpf_devel_QA.txt and describe somewhere in
the LLVM section of the doc the discussed issue around
gnu/stubs-32.h with possible workarounds, that would be great.
Thanks,
Daniel
Powered by blists - more mailing lists