This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [GOLD] Relayout?
The code in Script_section::create_segments does this:
else if (align_address(last_lma + last_size, abi_pagesize)
< align_address(lma, abi_pagesize))
{
// Putting this section in the segment would require
// skipping a page.
need_new_segment = true;
}
There is remote chance that relaxation causes segment size to change
so that different number of segements are required before and after a
relaxation pass. Should I just remove all segments and recreate them
to be safe?
-Doug
2009/8/24 Ian Lance Taylor <iant@google.com>:
> "Doug Kwan (Ãö®¶¼w)" <dougkwan@google.com> writes:
>
>> 2009/8/24 Ian Lance Taylor <iant@google.com>:
>>
>>> This does not make sense conceptually, at least in my concept of layout.
>>> When we reach Layout::finalize, the linker is supposed to know the final
>>> sizes of all normal sections. Layout::finalize then handles creating
>>> the symbol table, the dynamic section and so forth. Running that code
>>> again does not make sense.
>>
>> Unfortunately, stubs have symbols and they get exported by currently
>> by gnu ld. The ARM ELF specs say that veneer symbols have the same
>> visibility as the symbols they veneered. So the we need to rebuild
>> the dynamic symbol table at least.
>
> Well, I think that all we need to change is the size of the dynamic
> symbol table. But that might not really be any simpler.
>
>
>>> So I don't think unfinalize is conceptually the way to go. I think the
>>> right approach is going to be along the lines of doing the first step of
>>> finalization (compute the dynamic symbol table, et. al.), then a loop
>>> which sets section addresses and calls a target specific relaxation
>>> routine, then the last step of finalization (compute the regular symbol
>>> table, et. al.).
>>
>> That sound's simpler. Maybe I should pursue along this line and add
>> capability to rebuild the dynamic symbol table incrementally? We
>> always add relocation stubs during relaxation so the dynamic symbol
>> table can only grow.
>
> OK.
>
> Ian
>