From: Dodji Seketeli <dodji@seketeli.org>
To: "Matthias Männich" <maennich@google.com>
Cc: "Guillermo E. Martinez" <guillermo.e.martinez@oracle.com>,
Giuliano Procida <gprocida@google.com>,
Nick Desaulniers <ndesaulniers@google.com>,
elena.zannoni@oracle.com, "Cestmir Kalina" <ckalina@redhat.com>,
clang-built-linux <llvm@lists.linux.dev>
Subject: Re: Kernel ABI Monitoring and toolchain support
Date: Fri, 24 Jun 2022 11:03:14 +0200 [thread overview]
Message-ID: <86iloqtovh.fsf@seketeli.org> (raw)
In-Reply-To: <CAJFNNnoWDS547q-MDye4L_2WkT9odxAvhD2JQkALH7Erm2YJtQ@mail.gmail.com> ("Matthias \=\?utf-8\?Q\?M\=C3\=A4nnich\=22's\?\= message of "Mon, 20 Jun 2022 14:42:31 +0100")
Hey,
Matthias Männich <maennich@google.com> a écrit:
> That is a very late response, sorry about that.
No problem Matthias :-)
I totally forgot about this thread to begin with, so thank you for
reviving it.
> In the Android MC we will have a talk about the latest news monitoring
> Android Kernel ABIs already, but I definitely see value in a more
> generic session in the Kernel+Toolchain MC. Is that schedule already
> finalized or is there still a slot available and interest from your
> side?
>
> In particular, I would be interested in discussing ways to standardize
> ABI and type information in a way that it can be embedded into
> binaries in a less ambiguous way. In other words, what can we do to
> not rely entirely on intermediate formats like CTF or DWARF to make
> sense of an ABI? Maybe CTF is already a good starting point, yet some
> additions are needed (e.g. other language features like for C++)?
Do you have something in particular in mind, Matthias? I am very
curious about this. I know the idea is to discuss this at the
conference, but a little bit of a teaser would be awesome, I guess ;-)
Cheers,
>
> Cheers,
> Matthias
>
>
> On Sat, May 7, 2022 at 3:15 AM Guillermo E. Martinez
> <guillermo.e.martinez@oracle.com> wrote:
>>
>> Hello guys,
>>
>> On our side we are working on:
>>
>> * Gives the support to extract the ABI for Linux kernel image
>> and Linux kernel modules using the CFT backed in with
>> libabigail tools.
>> * Add support to compare packages with CTF debug format by using
>> abipkgdiff and other related libabigail tools.
>>
>> * https://sourceware.org/pipermail/libabigail/2022q2/004340.html
>> * https://sourceware.org/pipermail/libabigail/2022q2/004345.html
>>
>> If you think that it could be a point to talk as part of your MC, I can for sure
>> provides more details about it.
>>
>> Thanks for your comments,
>> Guillermo
>>
>> On Wednesday, April 20, 2022 12:34:59 PM CDT Giuliano Procida wrote:
>> > Sorry for the late reply, I've been on leave and Mattias is still on leave.
>> >
>> > That sounds quite interesting.
>> >
>> > Matthias and I could certainly talk about what we've been busy with and
>> > what are the main pain points for Android (not just the kernel).
>> >
>> > On what more would we like from the toolchain... it falls into at least two
>> > buckets:
>> >
>> > 1. make the possible easier - stricter conformance to DWARF standards, full
>> > DWARF 5 support, getting things like ARM64 ABI extensions (e.g., for
>> > HWASAN) into things like elfutils at the same time as the compile-link
>> > toolchain, more consistency between Clang and GCC debug info for the same
>> > sources, the same for Clang and Clang with full LTO
>> > 2. make the impossible possible - extending ABI monitoring coverage beyond
>> > just architecture, symbols and types / dealing with header constants,
>> > macros and more
>> >
>> > Giuliano.
>> >
>> >
>> > On Wed, 20 Apr 2022 at 17:02, Jose E. Marchesi <jose.marchesi@oracle.com>
>> > wrote:
>> >
>> > >
>> > > [Adding Dodji Seketeli, libabigail maintainer,
>> > > and Guillermo Martinez, who works in the CTF support for libabigail
>> > > including kernel support.]
>> > >
>> > > > Hi Matthias and Giuliano,
>> > > > Jose and I are currently in the planning process to put together a
>> > > > Kernel+Toolchain microconference track at Linux Plumbers Conference
>> > > > this year (Sept 12-14) in Dublin, Ireland.
>> > > >
>> > > > Would you all be interested in a leading session on Kernel ABI
>> > > > Monitoring and perhaps what toolchain vendors can do to help, as part
>> > > > of our MC (which itself is currently still in planning phase).
>> > >
>> >
>>
>>
>>
>>
--
Dodji
prev parent reply other threads:[~2022-06-24 9:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 21:33 Kernel ABI Monitoring and toolchain support Nick Desaulniers
2022-04-20 16:02 ` Jose E. Marchesi
[not found] ` <CAGvU0H=sjwsWEmq1R7LKHiPjB3aBkzQ_qJqXDxhT_rFJShgVFg@mail.gmail.com>
2022-05-07 2:15 ` Guillermo E. Martinez
2022-06-20 13:42 ` Matthias Männich
2022-06-21 21:19 ` Nick Desaulniers
2022-06-21 21:27 ` Elena Zannoni
2022-06-22 2:14 ` Guillermo E. Martinez
2022-06-22 15:27 ` Guillermo E. Martinez
2022-06-22 19:47 ` Nick Desaulniers
2022-06-23 11:54 ` Dodji Seketeli
2022-06-24 9:03 ` Dodji Seketeli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86iloqtovh.fsf@seketeli.org \
--to=dodji@seketeli.org \
--cc=ckalina@redhat.com \
--cc=elena.zannoni@oracle.com \
--cc=gprocida@google.com \
--cc=guillermo.e.martinez@oracle.com \
--cc=llvm@lists.linux.dev \
--cc=maennich@google.com \
--cc=ndesaulniers@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.