This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA:] Even more compact EH frame info for synchronous EH: migrate CFIs from FDEs to the CIE
- From: Richard Henderson <rth at redhat dot com>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 13 Apr 2005 20:02:55 -0700
- Subject: Re: [RFA:] Even more compact EH frame info for synchronous EH: migrate CFIs from FDEs to the CIE
- References: <200504132341.j3DNfZhD005097@ignucius.se.axis.com>
On Thu, Apr 14, 2005 at 01:41:35AM +0200, Hans-Peter Nilsson wrote:
> I could have iterated over the FDEs with a theoretically smarter
> algorithm to find a common opcode sequence; not requiring the
> sequence to be a prefix.
Except that DW_CFA_restore restores a column to the value it
had at the end of the CIE initial_instructions data. Which
means that you cannot in general make any changes to this data.
We do not currently emit DW_CFA_restore, but I believe there
are pending patches to properly instrument epilogues for
-fasynchronous-unwind-tables, at which point we would.
At minimum you'd have to verify that DW_CFA_restore does not exist
in any FDE to which you are going to apply this optimization.
> This time, not only EH info (.eh_frame) but also debug info
> (.debug_frame) is moved around, but to the "right" order; in
> which the info is generated, instead of reversing it as before
> (see queue_reg_save). Can't be wrong. I suspect there were
> some bugs caused by that; you could presumably not stepi inside
> that code and get correct values and certainly not get the right
> values for asynchronous EH.
Huh? All of these instructions were at the same address, surely.
If you could demonstrate a bug, then that bug must of necessity
be in the reader. The order in which the saves appear does not
matter.
I guess I'll have to look at the previous patch to figure out
what the hell you're doing here, but it looks Very Wrong.
r~