Re: [RFC,v2] x86_64: save_args out of line

[Ingo Molnar]

* Jan Beulich <jbeulich@xxxxxxxxxx> wrote:

> >>> Ingo Molnar <mingo@xxxxxxx> 18.11.08 15:03 >>>
> >* Jan Beulich <jbeulich@xxxxxxxxxx> wrote:
> >> No tool, if you mean that. Extensive changes I verify by looking at 
> >> the dump, problems are usually found only when back traces don't 
> >> come out right.
> >
> >that's a fundamental weakness of all the CFI annotations.
> >
> >It is outright wrong to waste humans on this mechanic task: as it is 
> 
> This part I agree to.
> 
> >abundantly clear to GAS where we change a stack pointer and by how 
> >much - it could emit magic annotations automatically just as much.
> >
> >So if you care about it, please fix this in the tools space. The 
> >entry_64.S impact of finegrained annotations is just too ugly for 
> >things like this.
> >
> >One limited exception is for basic stack frames where we do syscalls 
> >or call into other C code. (i.e. the patch proposed here would have to 
> >do that limited annotation)
> >
> >But the per instruction annotations currently in that code are madness 
> >and must either be cleaned up significantly via the use of GAS macros 
> >(so that all stack pointer manipulations go via a single macro 
> >invocation), or be completely auto-generated by GAS.
> 
> Making gas auto-generate this is not really possible (much like ia64 
> requires the annotations to be inserted manually), mainly because 
> gas can't know whether e.g. a push of a register is in order to 
> preserve its value, or for some other purpose.

but that's the exception. Most of the annotations could be 
auto-generated.

> I do have a set of macros for this in nlkd, maybe (as you're asking 
> for it) I should get them out of there (and convert them to AT&T 
> syntax).

i'd definitely like to have a look ...

if you can make this clean enough, most of the resistence to CFI 
annotations will go away.

The requirements is extreme cleanliness: single line in the source 
that gets us _both_ the instruction and the annotation. Also always 
insert the proper frame pointer as well, when we call into C. Make it 
as hard as possible to mess up the annotations - we could even run a 
build-time grep on the .S files that matter to see whether there's any 
(common) "naked" stack-manipulating instructions that shouldnt be 
used.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/