[PATCH] Add a fallback mechanism for undefined atom.

[Michael Spencer]

On Fri, Sep 6, 2013 at 1:37 PM, Nick Kledzik <kledzik at apple.com> wrote:

> I believe in iterative development, and that test cases are more important
> than the implementation.  That means that as long as the test cases for
> this feature have good coverage, we can later change the implementation
> have confidence that if the test suite passes, the new implementation is
> correct.
>
> So, I’m ok with committing this undef-fallback implementation as long as
> there are test cases for it.
>
> -Nick
>

Fully agreed here. Tests make it easy to change the impl.

- Michael Spencer


>
> On Sep 6, 2013, at 1:09 PM, Rui Ueyama <ruiu at google.com> wrote:
>
> 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
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130906/7f1f96de/attachment.html>