This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Invalid program counters and unwinding


On Mon, 2 Jul 2018, Jakub Jelinek wrote:

> > I disagree.  ASM code often lacks unwind descriptors (now less than in 
> > the past, but still).  My rule of thumb is always: no descriptor -> 
> > has to be a framepointer-using routine with standard calling sequence.  
> > (I.e. declare the combination of no descriptor and no fp to be a bug).  
> > Some of the callee-saved register will temporarily be wrong but 
> > unwinding can continue.
> Doesn't that clash with the x86-64 ABI which says what kind of FDE use 
> by default if none is found (essentially a standard leaf routine that 
> doesn't change sp, nor save any registers)?

There is no such language in the psABI, no (at least I haven't found 
anything; you had me worried for a moment :) ).  But there's stronger one: 
all functions through which unwinding is expected must provide CFI.  So, 
yes, such code isn't strictly conforming.  But there we are, there's much 
code that isn't and we still have to sensibly deal with it (if we can).  
IMHO making guesses is better than to stop unwinding.  And IMHO guessing 
that it's FP-using is better than guessing that it's leaf, especially if 
the PC in question was the result of a prior unwinding step (making it 
clear that it certainly was _not_ leaf).

And then there are (toy?) compilers that don't emit CFI, but do use FPs 
(totally psABI non-compliant, sure); IMHO we shouldn't pessimize them 
unduly.  Yeah, it's all a bit wonky, but why make it harder for those?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]