[lld] r258723 - Avoid almost duplication in .dynamic finalize and write.

Simon Atanasyan via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 2 02:05:11 PST 2016


On Wed, Jan 27, 2016 at 11:59 PM, Simon Atanasyan <simon at atanasyan.com> wrote:
> On Wed, Jan 27, 2016 at 9:41 PM, Rafael EspĂ­ndola
> <rafael.espindola at gmail.com> wrote:
>>>
>>> Size of RelocationSection is calculated in the
>>> RelocationSection::finalize() method. Before this commit we called the
>>> RelocationSection::getSize() method from the DynamicSection::writeTo()
>>> method and so we could be sure that size of the RelocationSection is
>>> calculated already. Now value of DT_PLTRELSZ depends on the order of
>>> finalize() calls. If RelocationSection::finalize() is called after the
>>> DynamicSection::finalize(), the DT_PLTRELSZ will be zero.
>>
>> Is that happening on some testcase or would you just like to make the order
>> more explicit?
>
> It cannot be reproduced on current trunk code. But the problem is in
> the output section order. If target uses writable .dynamic section,
> this section always goes after read-only sections i.e. .rel.plt{a}
> goes first. In that case the `finalize` method for .rel.plt{a} called
> before the same method for '.dynamic' section.
>
> But in case of MIPS .dynamic section is read-only. .dynamic and
> .rel.plt are grouped together. That is why it is possible that
> .dynamic goes before .rel.plt, and finalize methods called in wrong
> order.
>
> One possible solution is to fix compareOutputSections so if .dynamic
> section is read-only it goes after all other read-only sections. But
> that solution is rather limited. If in the future we allow user to
> specify custom section order using some sort of linker script, the
> user can easily get wrong result in the .dynamic section tags.

FYI

Fixed at r259478.

-- 
Simon Atanasyan


More information about the llvm-commits mailing list