Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Stephen Brennan <stephen.s.brennan@oracle.com>
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org,
        kexec@lists.infradead.org,
        Nick Desaulniers <ndesaulniers@google.com>,
        Dave Young <dyoung@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Jiri Olsa <jolsa@kernel.org>,
        Stephen Boyd <swboyd@chromium.org>,
        Bixuan Cui <cuibixuan@huawei.com>,
        David Vernet <void@manifault.com>,
        Vivek Goyal <vgoyal@redhat.com>,
        Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [PATCH 0/2] Expose kallsyms data in vmcoreinfo note
In-Reply-To: <20220613151422.e2173f14909b9149fec8e0a6@linux-foundation.org>
References: <20220517000508.777145-1-stephen.s.brennan@oracle.com>
 <20220613142609.3e4be0f2f45671341450232d@linux-foundation.org>
 <87edzsrzqn.fsf@oracle.com>
 <20220613151422.e2173f14909b9149fec8e0a6@linux-foundation.org>
Date:   Mon, 13 Jun 2022 15:33:19 -0700
Message-ID: <87bkuwry6o.fsf@oracle.com>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?IySL1i3xkNC1C94iZqnl/ydC4NUAvVHaBicmAz6nFSLDDNoLs3v1Kn+HJ1X+?=
 =?us-ascii?Q?vtFErhCgGv3ktpcZS/4uqZenW1vnWCGz/GA2Mdb7esvyWZgC6Dlg4yOao4Xb?=
 =?us-ascii?Q?Y/J6QIiQsDxNtJogSn9bUctUvCL6e38TwINK0H+CquwiyrOuxoGNeDMwtYXy?=
 =?us-ascii?Q?L+FCmdCM/YBQ6wtfC09dMzibJWOpCCgx0SQKeloSP075bdgHBiagHug51qKz?=
 =?us-ascii?Q?uQ/SYazBZ47c0yBRXAiL/0trKp4SF51YkKVPBbw924AJW1Hz3d/CCfG5ZJTE?=
 =?us-ascii?Q?Ut70reowIFGmav14VDjjjlHPuVbjzLQiZlhsvIqcYJGtEmBIDASQ+Ahq5c3n?=
 =?us-ascii?Q?hIkdRvPrJzoxO4zcP9mgJ+x+Jkz4wWNL0hTIquS7ClGR3tNbSiUJU+bPGj5S?=
 =?us-ascii?Q?n+pz5OiZa7jrSOD6Y+GrQq9Pc9Ob4wuJzG8YEmY4Zw5UR3p/ys0mj59ec4DI?=
 =?us-ascii?Q?aICOs8WcoB70gupyglgdq79NiTXpglpuVzVe4PAkfCusPuiE/5Urt/f7ux4E?=
 =?us-ascii?Q?RgDK5dzn8Ku0nJrXE8J5UpvUjD0itCTxWHsTz9noLMKD1wdG0fPjoGz04drC?=
 =?us-ascii?Q?BMA7ryORjOBLgFe6bauwqgQJNC5sFtkQ9Q7VFP+r+jHWMrU7G/6J4PY3aj3/?=
 =?us-ascii?Q?Tmw0A1Aum6FH8GF+a9FjNJNPwfujFhtWZFLLwNb6hqEIWw9zjILYnN5IVodo?=
 =?us-ascii?Q?P/2CqYKU78VRoPpTxwewWTAd8+suur6nJWj7MHE/fA2w8ocE4Ztf3gdY08aB?=
 =?us-ascii?Q?0NBSGrcVR0I3CCgbeBQ/1JW//xPLlBxdoKv8xtzMwxfWrAGszvXag0s2Rvv9?=
 =?us-ascii?Q?j/MquLinLGE7Snjnln24WIKvkAdoNw/QB3I1t4W5JSoYsfW6TH9TGMAKBQDR?=
 =?us-ascii?Q?HGwNHdz5nnQq/TsitAD9mQOEOMzRAKHdJMOUHyd2eRUzcr9VdYULKJnRWy0c?=
 =?us-ascii?Q?4GOAqnGWjqOHylOrCkM6rvBLx/PI5wNh2mSCzEMktTWxRV+zT5DEWlgQ4Z73?=
 =?us-ascii?Q?cFNikFAVogrX/FziXnGFTC2/O6IrQW44zlG9S4f//pIdrrt0mTPyLfcbSkF3?=
 =?us-ascii?Q?NS0Z4aQB7Q0a3ESuqbm+OhvlEO8astSKwGpe3u+JhAjW1YqmqM/OqVy5Tkpw?=
 =?us-ascii?Q?XkE7EOSK04fSDqDlDy8chKvItdtbLBf6bJawR15sI6S+XJ9VkeMQS5MMiZJb?=
 =?us-ascii?Q?Ia9Skflsw9uORyJl7opMwcTkiNi/+Z6onja7ZjCP5NCNglJ+0h/ZfmgjdVVH?=
 =?us-ascii?Q?U6Z/xdGjx+R+atxG7LDFYIbxcZLVWGRTY8iRnXuw3Gr0zq2s55lvqtsrMTNp?=
 =?us-ascii?Q?QQPOMU812C7l9bDDw5+r0P3+s0CmcZ1eMSYmIsBxm+oXVTFlHNEMsTDDN1w1?=
 =?us-ascii?Q?47z6cRBM8yUufA51YBKUsVTHC8bR0dyL2Nf7fj5eEBJNxDCu1jj//JtpbDCx?=
 =?us-ascii?Q?2OUj9BawR7E1/6sbbnZUzZxWJdTfTgH9AcSmCplabD7yhvvTRzZFRNTNzslR?=
 =?us-ascii?Q?Isc9Gep2GaodOZE1wErMXJzi7bnFqAtJ1oZP63k8RvB+yewzlVi7XdkNYKwu?=
 =?us-ascii?Q?OrL5+vUqI1oXiMnwW1X/ivCdtBMUsQZeUQXDVWewLhJGfby9R0SeXR8PrxQq?=
 =?us-ascii?Q?5vnohHGmK/MBcKNfQEGH4IavDU367MEA2uy/5kD9k0/pAocnxHcJUaozwrAA?=
 =?us-ascii?Q?npOuwh25RbJpql71NdxJ2XGI41i+5+aeJdlkO6v6Su+6c1jsFpAKSamPzzPy?=
 =?us-ascii?Q?M/G+mlo8tftX+pcyYnT3WZyz11g4TKo=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e530a24-994e-405c-6e75-08da4d8cc28f
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4166.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2022 22:33:38.2848
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: EZ/nSPx8vDV2hBGgmIQAIhq8jGQyl9AVHN5iDaix7dFIVTi1mg739nzb9jWAtrH20Zjdif6BkkkqeGCoSQPtzQ9ZFoQGXz9ts+cbeac/z7k=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1700
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.874
 definitions=2022-06-13_09:2022-06-13,2022-06-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 adultscore=0
 mlxlogscore=999 mlxscore=0 bulkscore=0 phishscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000
 definitions=main-2206130087
X-Proofpoint-ORIG-GUID: 6bFxqgDKLeBQcg2rQpCfQUP2WYZdbF-l
X-Proofpoint-GUID: 6bFxqgDKLeBQcg2rQpCfQUP2WYZdbF-l
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Andrew Morton <akpm@linux-foundation.org> writes:
> On Mon, 13 Jun 2022 14:59:44 -0700 Stephen Brennan <stephen.s.brennan@oracle.com> wrote:
>> >> Related discussion around the BTF side of this:
>> >> https://lore.kernel.org/bpf/586a6288-704a-f7a7-b256-e18a675927df@oracle.com/T/#u
>> >> 
>> >> Some work-in-progress branches using this feature:
>> >> https://github.com/brenns10/dwarves/tree/remove_percpu_restriction_1
>> >> https://github.com/brenns10/drgn/tree/kallsyms_plus_btf
>> >
>> > What's the story on using gdb with this?
>> 
>> There is no story with GDB as of yet. I was already familiar with the
>> code of drgn when I started down this path, so that's what I used. Drgn
>> happens to have a very extensible type system which made it quite simple
>> to do. I'd love to see support for doing this with GDB, and might look
>> into the feasibility of it, but it's not on my roadmap right now.
>
> Naive question - could some standalone tool take this kallsyms-based
> info, combine it with a core image and create a minimally-dwarfified
> file which any debugger can munch on?

I'm not too familiar with the guts of DWARF, so honestly my guess may
not be any better than yours.

One thing that strikes me is that DWARF is typically included in an ELF
section, whereas x86_64 kernels are typically a bzImage, so I'm not
entirely sure how you'd get back an ELF file suitable to stick the DWARF
into. And from there, I really have no guess about the DWARF.

I will say that Compact Type Format (CTF) [1] is rather similar to BTF
in scope, and it already has support in the GNU Binutils. I'd imagine
that there's much more of a fighting chance of converting BTF to CTF and
getting GDB to use that instead.

[1] https://lwn.net/Articles/795384/

Stephen