[PATCH] D41105: [ELF] Fix placement of a sentinel entry in the .ARM.exidx section.

[Igor Kudrin via llvm-commits]

Maybe I can't fully understand? your idea, but to put the relocation we still need to find the reference section, so I can't see why this approach is simpler than the current code. And we still have to write EXIDX_CANTUNWIND?, so we can't get rid of  'ARMExidxSentinelSection::writeTo()' altogether. Am I right?


Best Regards,
Igor Kudrin
C++ Developer, Access Softek, Inc.
________________________________
From: Rafael Avila de Espindola <rafael.espindola at gmail.com>
Sent: Wednesday, December 13, 2017 4:56 AM
To: reviews+D41105+public+9917650116a4fc81 at reviews.llvm.org; Igor Kudrin; peter.smith at linaro.org; ruiu at google.com
Cc: aemerson at apple.com; emaste at freebsd.org; javed.absar at arm.com; llvm-commits at lists.llvm.org; kristof.beyls at arm.com; adhemerval.zanella at linaro.org; t.p.northover at gmail.com; kanheim at a-bix.com; james.molloy at arm.com; diana.picus at linaro.org; florian.hahn at arm.com
Subject: Re: [PATCH] D41105: [ELF] Fix placement of a sentinel entry in the .ARM.exidx section.

Igor Kudrin via Phabricator <reviews at reviews.llvm.org> writes:

> +    // Find the last existing InputSectionDescription.
> +    // Add a new only if we cannot find one.
> +    // As a result, if we have a description for an output section like
> +    // .foo : { *(.foo) bar = . }
> +    // we will place the new section before the assignment so that it will
> +    // affect the value of 'bar', which is, probably, expected.
> +    // We also had a crash in the similar situation with an .ARM.exidx sentinel,
> +    // because 'ARMExidxSentinelSection::writeTo()' expected it to be placed
> +    // into a non-empty bucket.

I would actually find the result surprising in the general case.

I think we can just make the exidx code more resilient. Instead of
having a special handling in writeTo, could we push a relocation to the
Relocations vector of the sentinel entry?

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171213/70d2e316/attachment.html>