[PATCH] Add a fallback mechanism for undefined atom.

Rui Ueyama ruiu at google.com
Fri Sep 6 13:09:47 PDT 2013


That's again slightly different from simple symbol aliasing, because with
--wrap, *symbol* will be resolved to __wrap_*symbol*, while
__real_*symbol*is resolved to
*symbol*. In this case aliasing is not transitive. Anyways, I don't think
that should block this patch.


On Fri, Sep 6, 2013 at 1:03 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:

> Hi Ruiu,
>
> We need the functionality for ELF too to implement the --wrap
> functionality.
>
> Thanks
>
> Shankar Easwaran
>
>
> On 9/6/2013 2:58 PM, Rui Ueyama wrote:
>
>> Guys,
>>
>> I want to submit this patch. This patch is one of the last few patches
>> that
>> I need to link against the standard C++ library on Windows. Symbol
>> aliasing
>> does not seems to be needed for ELF. For Mach-O we need the feature, but
>> how to implement can be discussed later. This patch is short and not
>> intrusive, so it won't hurt anyone.
>>
>>
>> On Tue, Sep 3, 2013 at 1:07 PM, Shankar Easwaran <shankare at codeaurora.org
>> >**wrote:
>>
>>  On 9/3/2013 2:59 PM, Nick Kledzik wrote:
>>>
>>>  On Sep 3, 2013, at 12:51 PM, Shankar Easwaran <shankare at codeaurora.org>
>>>> wrote:
>>>>
>>>>   On 9/3/2013 2:36 PM, Nick Kledzik wrote:
>>>>
>>>>> On Sep 3, 2013, at 11:06 AM, Rui Ueyama <ruiu at google.com> wrote:
>>>>>>
>>>>>>  Nick, does Mach-O need symbol aliasing to be handled in the linker?
>>>>>>>
>>>>>>>  Yes.  The darwin linker has command line options for adding aliases.
>>>>>>
>>>>>> Back when I first started working on the darwin linker, a big
>>>>>> complaint
>>>>>> from the compiler team was that mach-o did not support aliases like
>>>>>> ELF
>>>>>> did, so the compiler team kept having to special case lots of test
>>>>>> cases
>>>>>> and functionality that used __attribute__((alias(“xx”))) on darwin.
>>>>>>
>>>>>>
>>>>>>   looks like ELF also needs the same functionality for implementing
>>>>>>
>>>>> __wrap.
>>>>>
>>>>> But in the case of the linker dealing with compiled .o's, the alias
>>>>> information is lost.
>>>>>
>>>>>  Really?  I thought ELF had a way to encode this.   I’ve received bug
>>>> reports saying that mach-o should support it too.
>>>>
>>>>  Example :-
>>>
>>> $cat x.c
>>> void __f () { /* Do something. */; }
>>>            void f () __attribute__ ((weak, alias ("__f")));
>>> $gcc -c x.c
>>> $readelf -s x.o
>>>
>>> Symbol table '.symtab' contains 10 entries:
>>>     Num:    Value  Size Type    Bind   Vis      Ndx Name
>>>       0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
>>>       1: 00000000     0 FILE    LOCAL  DEFAULT  ABS x.c
>>>       2: 00000000     0 SECTION LOCAL  DEFAULT    1
>>>       3: 00000000     0 SECTION LOCAL  DEFAULT    2
>>>       4: 00000000     0 SECTION LOCAL  DEFAULT    3
>>>       5: 00000000     0 SECTION LOCAL  DEFAULT    5
>>>       6: 00000000     0 SECTION LOCAL  DEFAULT    6
>>>       7: 00000000     0 SECTION LOCAL  DEFAULT    4
>>>       8: 00000000     5 FUNC    GLOBAL DEFAULT    1 __f
>>>       9: 00000000     5 FUNC    WEAK   DEFAULT    1 f
>>>
>>>
>>>
>>>    Does Darwin keep the alias information when the
>>>>
>>>>> __attribute__((alias(“xx”)) is used.
>>>>>
>>>>>  What the current darwin linker does is if parses a .o file and there
>>>> are
>>>> two symbols at the same address (and same section), it picks one to be
>>>> the
>>>> atom name (call it “foo”) and the other (call it “bar”) is turned into
>>>> an
>>>> alias atom (zero size and atom foo must layout after atom bar)
>>>>
>>>>  We do something very similiar in lld in the ELF reader, except that we
>>> dont alias it(as we need the content of the original atom, for the linker
>>> to abide the section property).
>>>
>>> Thanks
>>>
>>> Shankar Easwaran
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>>> by the Linux Foundation
>>>
>>>
>>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130906/0dbda05a/attachment.html>


More information about the llvm-commits mailing list