Re: [GOLD] Relayout?

[=?big5?b?RG91ZyBLd2FuICjD9q62vHcp?= <dougkwan at google dot com>]

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
>