<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-08-03 4:47 GMT+03:00 Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The patch as is crashes on linkerscript-provide-in-section.s. It is ok<br>
to turn into an error if something is wrong, but please don't crash.<br>
<br>
Cheers,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Rafael, this patch deletes that test case, it's strange that you've got this crash.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
On 2 August 2016 at 18:23, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On Tue, Aug 2, 2016 at 3:15 PM, Eugene Leviant <<a href="mailto:evgeny.leviant@gmail.com">evgeny.leviant@gmail.com</a>><br>
> wrote:<br>
>><br>
>><br>
>><br>
>> 2016-08-03 0:55 GMT+03:00 Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>>:<br>
>>><br>
>>> On Tue, Aug 2, 2016 at 2:45 PM, Eugene Leviant <<a href="mailto:evgeny.leviant@gmail.com">evgeny.leviant@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> среда, 3 августа 2016 г. пользователь Rui Ueyama написал:<br>
>>>>><br>
>>>>> On Tue, Aug 2, 2016 at 3:00 AM, Eugene Leviant<br>
>>>>> <<a href="mailto:evgeny.leviant@gmail.com">evgeny.leviant@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> evgeny777 added a comment.<br>
>>>>>><br>
>>>>>> I think the main reason, we're using virtual input sections is that<br>
>>>>>> this the only way to calculate correct symbol offset. As you may know<br>
>>>>>> location counter is not incremented while we add input sections to output<br>
>>>>>> section, and the true size of input sections is known only after call to<br>
>>>>>> OutputSectionBase<ELFT>::assignOffsets().<br>
>>>>>><br>
>>>>>> So if you suggest an algorithm, which can calculate correct symbol<br>
>>>>>> value (w/o using virtual input sections) in the case below:<br>
>>>>>><br>
>>>>>>   .foo : { *(.foo); end_foo = .; *(.bar) }<br>
>>>>>><br>
>>>>>> then we can probably switch to absolute symbols (BTW we can also use<br>
>>>>>> synthetic symbols - there is a little difference, if any).<br>
>>>>>> Another interesting question is what will happen if we define absolute<br>
>>>>>> symbol in shared object and reference it in executable? For example:<br>
>>>>>><br>
>>>>>>   /* script for linking shared library */<br>
>>>>>>   SECTIONS { .text : { text_start = .; *(.text) } }<br>
>>>>>><br>
>>>>>> So, when shared library is loaded by application, what value would<br>
>>>>>> text_start have, in case it is absolute? I don't know yet, but will try.<br>
>>>>><br>
>>>>><br>
>>>>> At first, I suggested you use empty dummy input sections to define<br>
>>>>> linker-script-defined symbols in the hope that in that way we don't need to<br>
>>>>> fix symbol addresses later (I was hoping that symbol addresses are<br>
>>>>> automatically fixed as attached input sections get final output addresses.)<br>
>>>>> Now that we know it doesn't work for many possible use cases. Then maybe we<br>
>>>>> want to eliminated dummy sections and directly define symbols as absolute<br>
>>>>> (or section) symbols.<br>
>>>><br>
>>>><br>
>>>> Like I said, the main problem is calculating this "absolute value". How<br>
>>>> are you going to do this? Also, like George said, it is not correct to use<br>
>>>> absolute values for symbols defined inside output section description<br>
>>><br>
>>><br>
>>> I think you don't need to calculate absolute values. We know the relative<br>
>>> distance from beginning of the current output section and the current "."<br>
>>> value, so we can create a DefinedSynthetic symbol with the output section<br>
>>> and the relative offset.<br>
>>><br>
>> Still have to deal with thunks, changing input section size, no?<br>
><br>
><br>
> Yes. But even with the current two-pass approach, I think the<br>
> above-mentioned logic should work.<br>
><br>
>><br>
>><br>
>><br>
>>>><br>
>>>><br>
>>>>><br>
>>>>> In this patch, you are trying to support assignments to symbols.<br>
>>>>> However, we eventually want to support something like this, too.<br>
>>>>><br>
>>>>>   SECTIONS { .text : { foo.o(.text); . = ALIGN(128); bar.o(.text) } }<br>
>>>><br>
>>>><br>
>>>> I do not see any problem in doing this. I think we use the same<br>
>>>> SymbolInputSection<ELFT> but with non-zero size, so proper layout will be<br>
>>>> calculated automatically in assignOffsets. Does this make sense?<br>
>>><br>
>>><br>
>>> I don't think so. Does it work for more complicated inputs, such as<br>
>>><br>
>>>   SECTIONS {<br>
>>>     .data { *(.data) }<br>
>>>     .text : { foo.o(.text); . += SIZEOF(.data); bar.o(.text) }<br>
>>>   }<br>
>>><br>
>>> ?<br>
>><br>
>><br>
>> I think making InputSectionBase<ELFT>::getSize() a virtual method will<br>
>> solve the problem, won't it?<br>
><br>
><br>
> It makes getSize() really complicated, no? If the expression is ". =<br>
> SIZEOF(.data) + ALIGN(100)", the input section need to understand the size<br>
> of the output .data section as well as the current dot value. Also, no input<br>
> sections have vtables now, so adding it only for getSize is probably too<br>
> much.<br>
><br>
>><br>
>><br>
>>><br>
>>><br>
>>>>><br>
>>>>><br>
>>>>> Looks like this doesn't fit to the current architecture. Currently, we<br>
>>>>> create a list of input sections and assign them addresses later. But in<br>
>>>>> order to process the above script, one pass would fit well. So I'm wondering<br>
>>>>> if we should merge LinkerScript::createSections and<br>
>>>>> LinkerScript::assignOffsets.<br>
>>>><br>
>>>><br>
>>>> How can this be done? We have createThunks() in between.<br>
>>><br>
>>><br>
>>> Yeah, we have Thunks. I haven't thought enough about that yet. But why we<br>
>>> can't create thunks earlier, even before createSections?<br>
>><br>
>><br>
>> Is this possible? As far as I understand thunk contains jump. which can be<br>
>> between two input sections (or even output sections). Until you create full<br>
>> layout (like we do in createSections), it looks<br>
>> like a tough problem to solve.<br>
><br>
><br>
> Well, I believe it's at least technically doable (I'm not sure how hard it<br>
> is). When the Writer is called, all symbols are resolved, so all relocations<br>
> should know where they point to. That means it can be determined whether<br>
> they need thunks or not.<br>
><br>
>><br>
>><br>
>>><br>
>>><br>
>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> ================<br>
>>>>>> Comment at: ELF/LinkerScript.cpp:278<br>
>>>>>> @@ -176,3 +277,3 @@<br>
>>>>>>  // Process ONLY_IF_RO and ONLY_IF_RW.<br>
>>>>>>  template <class ELFT> void LinkerScript<ELFT>::filter() {<br>
>>>>>>    // In this loop, we remove output sections if they don't satisfy<br>
>>>>>> ----------------<br>
>>>>>> ruiu wrote:<br>
>>>>>> > Why did you have to make a change to this function?<br>
>>>>>> Two main reasons:<br>
>>>>>><br>
>>>>>> 1) During filtering process some output sections may be removed. Those<br>
>>>>>> sections may contain symbols and SymbolInputSection object have already been<br>
>>>>>> created for them. To avoid crashes and/or creating dummy symbols I have to<br>
>>>>>> remove those virtual sections as well<br>
>>>>>><br>
>>>>>> 2) The old implementation is not technically correct, because it<br>
>>>>>> removes only first output section found in name lookup. We're still using<br>
>>>>>> OutputSectionFactory<ELFT>, so we may have several sections with the same<br>
>>>>>> name.<br>
>>>>>><br>
>>>>>> Another reason (though much less significant) is that one-by-one<br>
>>>>>> removal from std::vector must be slow, because it stores elements on<br>
>>>>>> continuous region of memory.<br>
>>>>>><br>
>>>>>><br>
>>>>>> <a href="https://reviews.llvm.org/D22683" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22683</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>><br>
>>><br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>