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

[Josh Poimboeuf <jpoimboe@redhat.com>]

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