[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
jakub at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Feb 10 19:13:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324
--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-10 18:49:08 UTC ---
Ugh, it is a mess. DW_CFA_expression/DW_CFA_def_cfa_expression location list
comes from 3 different routines:
1) build_cfa_loc
2) build_cfa_aligned_loc
3) mem_loc_descriptor
In 1) and 2) created location lists the register numbers embedded in it are GCC
internal hard register numbers transformed using DWARF_FRAME_REGNUM(reg) (and
it relies on being those, as it analyzes them and reconstructs from them too).
So, that is something that DWARF2_FRAME_REG_OUT macro should be applied on.
Then 3) contains GCC internal hard register numbers transformed using
DBX_REGISTER_NUMBER(reg). That is generally something that is supposed to be
usable only in .debug_* sections and DWARF2_FRAME_REG_OUT shouldn't be applied
on it. 3) happens just for REG_CFA_EXPRESSION, which is currently used only on
i386. And then output_loc_sequence is called also from places other than
output_cfa_loc*, and those again have mem_loc_descriptor like register numbers
in it and thus shouldn't be transformed using DWARF2_FRAME_REG_OUT.
Now, if we say rs6000 just can't use REG_CFA_EXPRESSION, we can simplify things
slightly. output_loc_sequence could have a 3 state parameter rather than bool,
-1 meaning don't use DWARF2_FRAME_REG_OUT macro, 0 use it with 0 as second
argument and 1 with 1 as second argument. Then output_loc_sequence callers
other than output_cfa_loc would pass in -1 and output_cfa_loc would pass in
for_eh. It is very ugly, but mainly because on those two targets we've screwed
things up.
More information about the Gcc-bugs
mailing list