[PATCH] Add a fallback mechanism for undefined atom.

[Nick Kledzik]

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

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 tosymbol. 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/d5c91e31/attachment.html>