On Thu, Jan 18, 2018 at 6:28 PM, Jakub Jelinek <ja...@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
