linux-kernel - Re: [PATCH v2 4/8] objtool: add undwarf debuginfo generation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170629140404.qgcvxhcgm7iywrkb@treble>
Date:   Thu, 29 Jun 2017 09:04:04 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        live-patching@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>, Jiri Slaby <jslaby@...e.cz>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2 4/8] objtool: add undwarf debuginfo generation

On Thu, Jun 29, 2017 at 09:25:12AM +0200, Ingo Molnar wrote:
> > +/*
> > + * This struct contains a simplified version of the DWARF Call Frame
> > + * Information standard.  It contains only the necessary parts of the real
> > + * DWARF, simplified for ease of access by the in-kernel unwinder.  It tells
> > + * the unwinder how to find the previous SP and BP (and sometimes entry regs)
> > + * on the stack for a given code address (IP).  Each instance of the struct
> > + * corresponds to one or more code locations.
> > + */
> > +struct undwarf {
> > +	short cfa_offset;
> > +	short bp_offset;
> > +	unsigned cfa_reg:4;
> > +	unsigned bp_reg:4;
> > +	unsigned type:2;
> > +};
> 
> I never know straight away what 'CFA' stands for - could we please use natural 
> names, i.e. something like:
> 
> struct undwarf {
> 	u16		sp_offset;
> 	u16		bp_offset;
> 	unsigned	sp_reg:4;
> 	unsigned	bp_reg:4;
> 	unsigned	type:2;
> };
> 
> ...
> 
> struct unwind_hint {
> 	u32		ip;
> 	u16		sp_offset;
> 	u8		sp_reg;
> 	u8		type;
> };
> 
> ?
> 
> Also note the slightly cleaner vertical alignment, plus the conversion to more 
> stable data types: I believe various bits of tooling (perf and so) will eventually 
> learn about undwarf, so having a well defined cross-arch data structure is 
> probably of advantage.

I agree with all your suggestions.

(Though if we want to make it truly cross-arch, 'bp' should be 'fp', for
frame pointer.  But there were some objections to that, so I'll leave it
'bp' for now.)

> Since we are not bound by DWARF anymore, we might as well use readable names and 
> such?
> 
> Plus, shouldn't we use __packed for 'struct undwarf' to minimize the structure's 
> size (to 6 bytes AFAICS?) - or is optimal packing of the main undwarf array 
> already guaranteed on every platform with this layout?

Ah yes, it should definitely be packed (assuming that doesn't affect
performance negatively).

-- 
Josh