[lld] r238115 - [ELF] Fix lld when no unique sections is used

Sean Silva chisophugis at gmail.com
Fri May 29 21:05:53 PDT 2015


On Fri, May 29, 2015 at 8:08 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> The bug this fixed was caused by lld confusing two sections with the same
> name, so really easy to reproduce.
>
Sorry, I thought you were referencing the example I gave, not the test case
in the patch.

-- Sean Silva

>  On May 29, 2015 10:00 PM, "Sean Silva" <chisophugis at gmail.com> wrote:
>
>>
>>
>> On Thu, May 28, 2015 at 10:07 PM, Rafael Espíndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>>
>>> On May 28, 2015 6:55 PM, "Sean Silva" <chisophugis at gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Wed, May 27, 2015 at 9:19 PM, Rafael Espíndola <
>>> rafael.espindola at gmail.com> wrote:
>>> >>
>>> >> > It sort of got lost among the other points, but this was meant to be
>>> >> > accompanied by "and if the binary is created with yaml2obj anyway,
>>> why not
>>> >> > just check in the yaml?"
>>> >>
>>> >> So, there may be a line between the two groups where yaml is the
>>> >> easiest way to create a test. So lets say you are reading the code,
>>> >> notice something odd and decide to try create a file that will hit an
>>> >> assert. Depending on what that assert is, yaml2obj might be the tool
>>> >> for the job (or llvm-mc, or an hex editor depending on the assert).
>>> >>
>>> >> But most cases I have seen yaml2obj mentioned are for cases that
>>> >> someone chanced upon a file that causes an issue and now is trying to
>>> >> figure out a way to recreate it with yaml2obj. Since we will always
>>> >> want to do something reasonable with that file, why not check it in?
>>> >
>>> >
>>> > The same reason we generally reduce all other testcases before
>>> checking them in? I don't see how this is any different.
>>>
>>> The test is two  .section directives and a relocation in .s. Trying to
>>> force it to yaml is just a waste of time.
>>>
>>> Sorry, I'm not understanding how one would write a test case for an
>> overflowing relocation from assembly. Could you explain?
>>
>> -- Sean Silva
>>
>>> > -- Sean Silva
>>> >
>>> >>
>>> >>
>>> >> This patch was just one such case: the patch was written fixing an
>>> >> issue on a file that was trivial to create: compile a file with two
>>> >> functions using -ffunction-sections -fno-unique-section-names.
>>> >>
>>> >> Cheers,
>>> >> Rafael
>>> >
>>> >
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150529/7774f14b/attachment.html>


More information about the llvm-commits mailing list