Re: Fix the .align bug with unwind info

["H. J. Lu" <hjl at lucon dot org>]

On Thu, Dec 18, 2003 at 10:29:46PM -0800, Jim Wilson wrote:
> On Thu, 2003-12-18 at 14:08, H. J. Lu wrote:
> > The problem is more complex than I thought. I also fixed .space and
> > .org. The main problem is to estimate the size of unwind record. Is
> > that possible to grow the rs_machine_dependent frag in
> > ia64_convert_frag?
> 
> I don't have a lot of experience with frags and relaxation.  I don't
> know if it is safe to grow a frag in ia64_convert_frag.  It might be
> useful to ask this on the binutils list, perhaps even along with the
> rest of the patch in case others want to comment.  I would think that
> growing the size of the variant frag here shouldn't cause any other
> frags to change in size, so maybe it can work.

I don't think we can grow a specific frag with the current gas. How
hard to support it?

> 
> It isn't immediately obvious to me why it is hard to estimate the size
> of the unwind info.  Looking at this though, I see that there are
> uleb128 encoded fields, and some variable sized fields, so yes, you
> won't be able to calculate the size until after relaxation.
> 
> I see you are trying to put the unprocessed unwind info inside a variant
> frag.  The dwarf2 code only uses a variant frag for info that can't be
> calculated until after relaxation.  If we do the same thing for the
> unwind info, then we would emit unwind info as normal, until we got
> something that we couldn't calculate immediately, and then create a
> variant frag for that little bit of info.
> 
> So if slot_index can't compute an exact value, then we save the
> frag/slot info into the current unwind record, and then when we emit the
> unwind record we create a variant frag that will call slot_index after
> relocation.  For instance, in output_R3_record, instead of calling
> output_leb128 we create a variant frag that has enough info to call
> slot_index or an equivalent function.  We can estimate the size of
> this.  rlen can be at most the size of the address space, 8 bytes, and
> if you uleb128 encode that, that is 10 bytes I think.
> 
> A possible problem with this approach though is that we need a number of
> different kinds of variant frags, one for each kind of unwind info
> fields that can't be computed before relaxation.  That might be a
> burden.  Most of them will be output_leb128 I think, but there are a few
> harder ones like imask.  Actually imask looks like a particularly hard
> one, since its size is roughly prologue rlen/4, and we can't have a
> variant frag 1/4 of the address space which is the worst case.  prologue
> regions should never be very big though, so putting a reasonable limit
> on this shouldn't be a problem in practice.  We can maybe even compute a
> theoretical limit on the size of a prologue, as there are only so many
> registers that can be saved.

If we have to estimate the size anyway, we don't need to add a bunch
of new variant frags. We just initialize the variant frag with a
reasonable size. The only thing which needs a limit is imask. What is
its reasonable limit for prologue rlen?

> 
> Does your patch work except for the problem of computing the size of the
> variant frag?  It looks like it might be working.  The only part not

Yes.

> clear to me is why there is a call to optimize_unw_records
> ia64_convert_frag.  It is already called in generate_image.  I don't see
> how this is useful after relaxation.

I removed optimize_unw_records.


H.J.

Attachment: gas-ia64-unwind-3.patch
Description: Text document