[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