[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170520171917.6vru6sohd2wvotw3@treble>
Date: Sat, 20 May 2017 12:19:17 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: "H. J. Lu" <hjl.tools@...il.com>, "H. Peter Anvin" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jiri Slaby <jslaby@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
live-patching@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
the arch/x86 maintainers <x86@...nel.org>,
Jiri Kosina <jikos@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 7/7] DWARF: add the config option
On Sat, May 20, 2017 at 11:20:34AM -0500, Josh Poimboeuf wrote:
> But then, if we're going that far, why not just have objtool reformat
> the data into something much simpler? It already has the knowledge
> to do so. Then we don't have to jump through all those hoops to
> justify jumping through more hoops in the kernel (i.e., having a
> complex DWARF state machine). With a simple debuginfo format, the
> kernel unwinder is simple enough that we don't need to validate its
> functionality in a simulator.
I should clarify that it doesn't have to be objtool which does this. It
could instead be a simple DWARF-to-undwarf conversion tool which runs
during the vmlinux linking stage.
Anyway we're both proposing simplifying the DWARF data into an
easier-to-parse format. I think the question is whether we want that
simplification process to happen in the kernel (in the middle of a
kernel unwind operation), or at build time.
--
Josh
Powered by blists - more mailing lists