[GOLD] How can I add a undefined symbol in target implementation, not by "-u SYM" from command line ?

[WANG.Jiong]

On 08/14/2012 01:26 PM, Ian Lance Taylor wrote:
> On Mon, Aug 13, 2012 at 9:53 PM, WANG.Jiong <wong.kwongyuan@gmail.com> wrote:
>> On 08/14/2012 12:39 PM, Ian Lance Taylor wrote:
>>> On Mon, Aug 13, 2012 at 8:30 PM, Jiong WANG <wong.kwongyuan@gmail.com>
>>> wrote:
>>>> 2012/8/13 Ian Lance Taylor <iant@google.com>:
>>>>> On Mon, Aug 13, 2012 at 3:25 AM, Jiong WANG <wong.kwongyuan@gmail.com>
>>>>> wrote:
>>>>>>     How can I predefine a undefined symbol in target implementation?
>>>>>>
>>>>>>     actually, I am porting gold for tilegx, and our arch's tls
>>>>>> implementation requires predefiniation of "_tls_get_addr" because the
>>>>>> assembler generate relocation which use this symbol implicitly.
>>>>>>
>>>>>>      I know there are interfaces,  "define_in_output_data/segment" to
>>>>>> predefined symbol with value, but there is no interface to predefine
>>>>>> "undefined" symbol ?
>>>>>>
>>>>>>      gold linker do support this by command line "-u SYMBOL",  but it's
>>>>>> a compile time decision not link time.
>>>>>>
>>>>>>      currently, I managed to support this by the following ugly code:
>>>>>>
>>>>>>       options::parse_set(NULL, "_tls_get_addr",
>>>>>> (gold::options::String_set*)&parameters->options().undefined());
>>>>>>
>>>>>>      which is bad, so, could anyone give me some suggestion on this?
>>>>>
>>>>> I assume that the symbol is defined somewhere.  You probably want to
>>>>> add a do_is_defined_by_abi method to your Target.  See the examples in
>>>>> existing targets.
>>>> Hi Ian & all, thanks for your suggestion.
>>>>
>>>> I have explored do_is_defined_by_abi, and found it's mostly to avoid
>>>> warning, but not for creating such a symbol
>>>>
>>>> do_is_defined_by_abi has one argument of the type "const Symbol*",  so
>>>> when it's invoked, that symbol should already existed.
>>>> ...
>>>>     basically, I want to create a symbol which is neither against
>>>> section or segment, just a normally external function symbol.
>>> I'm sorry, I don't understand what you mean.
>>>
>>> If there is no reference to __tls_get_addr in the object files, why do
>>> you care whether it is defined?
>>>
>>> If there is a reference in the object files, then where is it defined?
>>>
>>> You seem to be asking how to create an undefined symbol, as though
>>> used with the -u option.  But that makes no sense.  Why would you want
>>> that?  The purpose of the -u option is to add a reference to a symbol
>>> in order to fetch the definition from an archive.
>> Hi Ian,
>>
>>    thanks for reply.
>>
>>    suppose the following code:
>>
>>    __thread int gd_v = 0x10;
>>
>>    int cal(int a)
>>    {
>>       return a + gd_v;
>>    }
>>
>>   tilegx gcc will generate the following relocation:
>>
>> jal     tls_gd_call(gd_v),   tls_gd_call will actually need linker to treat
>> it like plt@__tls_get_addr
>>
>> while all other arch, arm/mips/x86 etc, will generate relocation against
>> __tls_get_addr explictly
>>
>> so, for tilegx arch,  the symbol "__tls_get_addr" will not exist in the .o
>> file, while for other arches, it will.
>>
>> from my understanding, I need to do the following two thing for tilegx arch:
>>
>>    1.  when scaned the tls_gd_call relocation, I need to create the symbol
>> "__tls_get_addr", and
>>         make a plt entry for it.
>>    2.  when apply relation for tls_gd_call, make the jal instruction jump to
>> plt entry for "__tls_get_addr"
>>
>> I found there are  interfaces like define_in_output_data etc which could
>> predefine symbol, but It seems
>> they can not defined a symbol with GLOBAL/UND type which is the type of
>> "__tls_get_addr"
>>
>> this is my problem.
> I see.  So you have a relocation type that refers to a symbol with a
> magic name.  That seems like a bad design to me.  Can you change it?
>
> If you can't change it, there is a phase ordering problem.  Gold reads
> all the symbol tables, including fetching objects out of archives,
> before it does the relocation processing.  You will only know that you
> need the symbol when you are doing relocation processing.  At that
> time, it is too late.
>
> As far as I can see, you will have to make the symbol always be
> undefined, as though the linker were always invoke with -u
> __tls_get_addr.  That will cause the object defining the symbol to
> always be brought into the link, but I don't see how to avoid that.
> You just need to call symtab->add_undefined_symbol_from_command_line,
> one way or another, and you need to do it early in the link, e.g.,
> when your Target is constructed.

Thanks Ian,

   got it. then I will temporarily handle this situation by using 
add_undefined_symbol_from_command_line.

   yeah, I also think it's a bad design to generate such style 
relocation. In old bfd linker, we support this by some tricky hacking also.

   I will talk with our gcc guy to change this.

---
Regards,
WANG.Jiong




>
> Ian