Re: [PATCH] Fix unwind info in x86 interrupt functions (PR debug/83728)

[Jason Merrill <jason at redhat dot com>]

On Thu, Jan 18, 2018 at 6:28 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Last summer i386 INCOMING_FRAME_SP_OFFSET macro has been changed, so that it
> is one word for most of the functions (as previously always), but 2 words
> for functions with interrupt attribute.
> Unfortunately this breaks the unwind info, as can be seen on the
> gcc.dg/guality/pr68037-1.c testcase.  Our infrastructure assumes we have
> just one set of cfi instructions in the CIE (we can have multiple CIEs, but
> only for various flags, not for different cfi instructions), so if
> the first function being assembled is an interrupt function, we start
> with the 2*word initial offset in the CIE we emit (when
> -fno-dwarf2-cfi-asm), or just assume the CIE has that (with -fdwarf2-cfi-asm
> when it is GAS that emits it) even when it doesn't.  For -fdwarf2-cfi-asm
> the effect is that until first CFA adjustment the offset is off by a word,
> after that correct.  In both cases all CFA offsets are off by a word in
> non-interrupt functions.
> Or, if the first function doesn't have interrupt attribute, CFI in
> non-interrupt functions is correct, but interrupt functions are wrong.
>
> I've looked around and it seems stormy16 is the only other target that
> bases the INCOMING_FRAME_SP_OFFSET value not just on ABI changing switches,
> but on properties of the current function.
>
> For these 2 targets the following patch introduces another macro,
> DEFAULT_INCOMING_FRAME_SP_OFFSET, that is meant to be the same for all
> functions of the same ABI and where GAS supports .cfi_startproc it should
> also match what GAS does.  For the hopefully minority of functions that
> need something else (i.e. interrupt functions) we emit a CFI instruction
> right at the start of the function.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, fixes the pr68037-1.c
> FAILs, ok for trunk?

OK, thanks.

Jason