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

[Igor Kudrin via llvm-commits]

Making the code for exidx sentinel crash-proof is only half of the deal in my case.

I still need the symbol in the assignment at the end of the section description to point after synthetic data, such as this sentinel or the space reservation for copy relocations. This is that both bfd and gold do, and our environment depends on that behavior. But, at the same time, as Peter noted, placement of orphan sections should not be affected.


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/663c59ee/attachment.html>