This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |