DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 43F0EC0C0568
Date: Thu, 29 Jun 2017 09:04:04 -0500
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
        live-patching@vger.kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andy Lutomirski <luto@kernel.org>, Jiri Slaby <jslaby@suse.cz>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 4/8] objtool: add undwarf debuginfo generation
Message-ID: <20170629140404.qgcvxhcgm7iywrkb@treble>
References: <cover.1498659915.git.jpoimboe@redhat.com>
 <e255ec17d43e4a22b58accb42380fe78250cafe8.1498659915.git.jpoimboe@redhat.com>
 <20170629072512.pmkfnrgq4dci6od7@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20170629072512.pmkfnrgq4dci6od7@gmail.com>
User-Agent: Mutt/1.6.0.1 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1923
Lines: 62

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