This is the mail archive of the
mailing list for the binutils project.
Re: [Gold] how to do relax in Gold ?
On Wed, Jan 16, 2013 at 12:24 AM, Shawn <firstname.lastname@example.org> wrote:
> On 2013å01æ16æ 14:09, Ian Lance Taylor wrote:
>> On Tue, Jan 15, 2013 at 10:02 PM, Shawn <email@example.com> wrote:
>>> Hi All:
>>> I'am porting Gold to our processor right now ,everything is fine
>>> the label whose value is big. For Example, the following instruction
>>> a LABEL value to register R0:
>>> R0 = LABEL_0;
>>> 1. Our Objects
>>> Our instruction is encoded in 32bit, if the value of "LABLE_0" is
>>> big, for example 0x40000, there is not enough space to encode the
>>> instruction into a 32bit instruction, we have to expand "R0 = LABEL_0"
>>> a 64bit instruction automatically.
>>> Because the value of "LABEL_0" is not known until link-time, we hope
>>> "Gold" can handle this .
>>> 2. My plan & Question:
>>> I found the function related to our object is the "Target::do_relax"
>>> function, but only arm.cc & powerpc.cc has overwritten it. The "do_relax"
>>> arm.cc & powerpc.cc is too complicate to analyze. I hope to get a clean
>>> implementation of Our Objects.
>>> a) Scan relocation info in all input objects, find the relocations
>>> may need relaxation ( read & compare the symbol value )
>>> How can I read the relocation info ?
>>> How can I reany advice ad the symbol value ? Is the value read
>>> from the Symbol_table represent the value after layout ?
>>> b) for each relocation that need relaxation, insert a 32bit stub in
>>> VIEW, and update the value of the symbol which is located after the
>>> relocation site.
>>> And is there any other example related to relaxation except arm.cc &
>>> powerpc.cc ? or any document ?
>> No, sorry.
>> I think one approach would be to record the possible relaxation points
>> in your scan_relocs routine. You will have all the relocation
>> information available there. That will let you detect out of range
>> relocations where you can insert stubs.
> Thanks Ian. Did your mean Target::scan_relocs ? I will try that.