PATCH: Fix handle implicit nops for unwind records
Jim Wilson
wilson@specifixinc.com
Sat Jan 31 10:02:00 GMT 2004
On Fri, 2004-01-16 at 14:52, H. J. Lu wrote:
> On Thu, Jan 15, 2004 at 12:13:11PM -0800, David Mosberger wrote:
> > One thing it still doesn't seem to get right is if there are implicit
> > nops at the beginning of a region. For example:
I finally got around to trying my suggestion. It ended up a little more
complicated than I had hoped, but it seems to be working well. This
patch works for the testcase David provided. I also tested it against
the Linux kernel. Quite a few prologue regions get one or two insns
shorter, because they no longer contain following nops. Also, quite a
few body regions that contain epilogue records get one of two insns
shorter, which reduces the epilogue count. These seem like desirable
changes. There are no other changes to the unwind info.
While doing this, I noticed that padding unwind records used to be all
zeros (R1:prologue(rlen=0)) but now we get occasional non-zero bytes in
there. This gives weird looking results when you dump the unwind
records. This is a side-effect of HJ's patch to use a variant frag for
the unwind info. I added a patch to fix that too.
I am also wondering if there is a problem with the personality routine.
I think we can get garbage there also when it is not set, but I don't
have a testcase for that, as readelf -u does not print the personality
routine when it isn't being used. I also noticed that we seem to have
overlapping frags when the personality routine is present. The
personality routine is a separate frag, but it is also included in the
size of the variant frag. I don't know if that is kosher, but it looks
funny to me. This doesn't cause an immediate problem because we don't
write to that part of the variant frag.
It being 2AM, I will wait until tomorrow to check it in. It also just
occurred to me that I forgot to run the binutils testsuite.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tmp.file.3
Type: text/x-troff-man
Size: 5023 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040131/bd55b2a8/attachment.bin>
More information about the Binutils
mailing list