Hi Nick,
In addition to what you mentioned, I think there needs a special
*AliasReference* that need to be created which the DefinedAtom points to.
Thanks
Shankar Easwaran
-------- Original Message --------
Subject: Re: [PATCH] Add a fallback mechanism for undefined atom.
Date: Thu, 29 Aug 2013 15:15:49 -0700
From: kledzik at apple.com <kledzik at apple.com>
Reply-To: reviews+D1550+public+25c98da67f89e22f at llvm-reviews.chandlerc.com
To: shankarke at gmail.com, kledzik at apple.com, bigcheesegs at gmail.com,
ruiu at google.com
CC: llvm-commits at cs.uiuc.edu
Interesting feature.
What happens if a.o has an undefine foo which says its fallback is bar, but
in b.o an undefine for foo says its fallback is baz? Is that an error, or does
each fallback apply to its original usage. The problem is that the Resolver is
currently coalescing UndefinedAtoms based on their name. I does not know that
fallbacks need to match too.
Another variant is to have Undefined return a alternate name as a string,
rather than returning a new UndefinedAtom object.
Another approach is to use weak aliases. That is if a.o has an undefine for
foo with a fallback of bar, that when parsing that .o file into atoms produces
an UndefinedAtom for foo, but also a DefinedAtom with name=foo, weak
(mergeAsWeak), hidden (scopeLinkageUnit), size=0, isAlias=true which aliases to
bar. So, it any definition of foo does show up, it will override the weak
alias. If not the weak alias will be used and change the reference to bar.
I don't think the isAlias support is all wired up in lld. But weak
aliases are something common in ELF. So would should get it working, and doing
so may provide a way to implement this COFF feature.
One issue is how this interacts with static libraries. The weak alias for
foo make look like there is a definition, so any static archives will not be
searched for foo. That seems different than what you want. I'm not sure
what the gnu linker does about this with weak aliases. We may need a new
resolver option as to how to handle this.
===============Comment at: lib/Core/Resolver.cpp:214
@@ +213,3 @@
+ // for COFF "weak external" symbol.
+ const UndefinedAtom *fallbackUndefAtom = undefAtom->fallback();
+ if (fallbackUndefAtom) {
----------------
You need to re-test:
if (!_symbolTable.isDefined(undefName)
because searchLibraries() may have already found a definition.
http://llvm-reviews.chandlerc.com/D1550
_______________________________________________
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-dev/attachments/20130912/8468137a/attachment.html>
Ping ? On 9/12/2013 5:02 PM, Shankar Easwaran wrote:> Hi Nick, > > In addition to what you mentioned, I think there needs a special > *AliasReference* that need to be created which the DefinedAtom points to. > > Thanks > > Shankar Easwaran > > > -------- Original Message -------- > Subject: Re: [PATCH] Add a fallback mechanism for undefined atom. > Date: Thu, 29 Aug 2013 15:15:49 -0700 > From: kledzik at apple.com <kledzik at apple.com> > Reply-To: > reviews+D1550+public+25c98da67f89e22f at llvm-reviews.chandlerc.com > To: shankarke at gmail.com, kledzik at apple.com, bigcheesegs at gmail.com, > ruiu at google.com > CC: llvm-commits at cs.uiuc.edu > > > > Interesting feature. > > What happens if a.o has an undefine foo which says its fallback is > bar, but in b.o an undefine for foo says its fallback is baz? Is that > an error, or does each fallback apply to its original usage. The > problem is that the Resolver is currently coalescing UndefinedAtoms > based on their name. I does not know that fallbacks need to match too. > > Another variant is to have Undefined return a alternate name as a > string, rather than returning a new UndefinedAtom object. > > Another approach is to use weak aliases. That is if a.o has an > undefine for foo with a fallback of bar, that when parsing that .o > file into atoms produces an UndefinedAtom for foo, but also a > DefinedAtom with name=foo, weak (mergeAsWeak), hidden > (scopeLinkageUnit), size=0, isAlias=true which aliases to bar. So, it > any definition of foo does show up, it will override the weak alias. > If not the weak alias will be used and change the reference to bar. > > I don't think the isAlias support is all wired up in lld. But weak > aliases are something common in ELF. So would should get it working, > and doing so may provide a way to implement this COFF feature. > > One issue is how this interacts with static libraries. The weak > alias for foo make look like there is a definition, so any static > archives will not be searched for foo. That seems different than what > you want. I'm not sure what the gnu linker does about this with weak > aliases. We may need a new resolver option as to how to handle this. > > > ===============> Comment at: lib/Core/Resolver.cpp:214 > @@ +213,3 @@ > + // for COFF "weak external" symbol. > + const UndefinedAtom *fallbackUndefAtom = undefAtom->fallback(); > + if (fallbackUndefAtom) { > ---------------- > You need to re-test: > if (!_symbolTable.isDefined(undefName) > because searchLibraries() may have already found a definition. > > > http://llvm-reviews.chandlerc.com/D1550 > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > > > >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
Can an “alias” atom just be a zero sized atom with one reference of kindLayoutBefore to its target? The layout engine should then place the alias atom right before the real atom, so you wind up with two symbols at one address. -Nick On Sep 12, 2013, at 3:02 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:> Hi Nick, > > In addition to what you mentioned, I think there needs a special *AliasReference* that need to be created which the DefinedAtom points to. > > Thanks > > Shankar Easwaran > > > -------- Original Message -------- > Subject: Re: [PATCH] Add a fallback mechanism for undefined atom. > Date: Thu, 29 Aug 2013 15:15:49 -0700 > From: kledzik at apple.com <kledzik at apple.com> > Reply-To: reviews+D1550+public+25c98da67f89e22f at llvm-reviews.chandlerc.com > To: shankarke at gmail.com, kledzik at apple.com, bigcheesegs at gmail.com, ruiu at google.com > CC: llvm-commits at cs.uiuc.edu > > > Interesting feature. > > What happens if a.o has an undefine foo which says its fallback is bar, but in b.o an undefine for foo says its fallback is baz? Is that an error, or does each fallback apply to its original usage. The problem is that the Resolver is currently coalescing UndefinedAtoms based on their name. I does not know that fallbacks need to match too. > > Another variant is to have Undefined return a alternate name as a string, rather than returning a new UndefinedAtom object. > > Another approach is to use weak aliases. That is if a.o has an undefine for foo with a fallback of bar, that when parsing that .o file into atoms produces an UndefinedAtom for foo, but also a DefinedAtom with name=foo, weak (mergeAsWeak), hidden (scopeLinkageUnit), size=0, isAlias=true which aliases to bar. So, it any definition of foo does show up, it will override the weak alias. If not the weak alias will be used and change the reference to bar. > > I don't think the isAlias support is all wired up in lld. But weak aliases are something common in ELF. So would should get it working, and doing so may provide a way to implement this COFF feature. > > One issue is how this interacts with static libraries. The weak alias for foo make look like there is a definition, so any static archives will not be searched for foo. That seems different than what you want. I'm not sure what the gnu linker does about this with weak aliases. We may need a new resolver option as to how to handle this. > > > ===============> Comment at: lib/Core/Resolver.cpp:214 > @@ +213,3 @@ > + // for COFF "weak external" symbol. > + const UndefinedAtom *fallbackUndefAtom = undefAtom->fallback(); > + if (fallbackUndefAtom) { > ---------------- > You need to re-test: > if (!_symbolTable.isDefined(undefName) > because searchLibraries() may have already found a definition. > > > http://llvm-reviews.chandlerc.com/D1550 > _______________________________________________ > 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-dev/attachments/20130913/4f179756/attachment.html>
Hi Nick, This would work only if an alias is another name for the same symbol(weak symbols). If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work. I was thinking to model this for ELF for the below functionalities :- a) __wrap For example : --wrap fn What I plan to do here is, create a undefined function fn atom create a defined weak atom fn create a alias reference to __wrap_fn which is a undefined atom. b) --defsym option For example : --defsym A = B the defsym option is going to have a undefined atom for A create a defined weak atom "B" of size 0 create a alias reference to the expression atom, that defines the expression. Both (a), (b) would work if there is an actual function fn, and a symbol A that can override. If there is no such symbol, whatever is being aliased to will take preference. Thanks Shankar Easwaran On 9/13/2013 5:26 PM, Nick Kledzik wrote:> Can an “alias” atom just be a zero sized atom with one reference of kindLayoutBefore to its target? The layout engine should then place the alias atom right before the real atom, so you wind up with two symbols at one address. > > -Nick > > On Sep 12, 2013, at 3:02 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > >> Hi Nick, >> >> In addition to what you mentioned, I think there needs a special *AliasReference* that need to be created which the DefinedAtom points to. >> >> Thanks >> >> Shankar Easwaran >> >> >> -------- Original Message -------- >> Subject: Re: [PATCH] Add a fallback mechanism for undefined atom. >> Date: Thu, 29 Aug 2013 15:15:49 -0700 >> From: kledzik at apple.com <kledzik at apple.com> >> Reply-To: reviews+D1550+public+25c98da67f89e22f at llvm-reviews.chandlerc.com >> To: shankarke at gmail.com, kledzik at apple.com, bigcheesegs at gmail.com, ruiu at google.com >> CC: llvm-commits at cs.uiuc.edu >> >> >> Interesting feature. >> >> What happens if a.o has an undefine foo which says its fallback is bar, but in b.o an undefine for foo says its fallback is baz? Is that an error, or does each fallback apply to its original usage. The problem is that the Resolver is currently coalescing UndefinedAtoms based on their name. I does not know that fallbacks need to match too. >> >> Another variant is to have Undefined return a alternate name as a string, rather than returning a new UndefinedAtom object. >> >> Another approach is to use weak aliases. That is if a.o has an undefine for foo with a fallback of bar, that when parsing that .o file into atoms produces an UndefinedAtom for foo, but also a DefinedAtom with name=foo, weak (mergeAsWeak), hidden (scopeLinkageUnit), size=0, isAlias=true which aliases to bar. So, it any definition of foo does show up, it will override the weak alias. If not the weak alias will be used and change the reference to bar. >> >> I don't think the isAlias support is all wired up in lld. But weak aliases are something common in ELF. So would should get it working, and doing so may provide a way to implement this COFF feature. >> >> One issue is how this interacts with static libraries. The weak alias for foo make look like there is a definition, so any static archives will not be searched for foo. That seems different than what you want. I'm not sure what the gnu linker does about this with weak aliases. We may need a new resolver option as to how to handle this. >> >> >> ===============>> Comment at: lib/Core/Resolver.cpp:214 >> @@ +213,3 @@ >> + // for COFF "weak external" symbol. >> + const UndefinedAtom *fallbackUndefAtom = undefAtom->fallback(); >> + if (fallbackUndefAtom) { >> ---------------- >> You need to re-test: >> if (!_symbolTable.isDefined(undefName) >> because searchLibraries() may have already found a definition. >> >> >> http://llvm-reviews.chandlerc.com/D1550 >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> >> >> >> >> >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
Seemingly Similar Threads
- [LLVMdev] [lld] Implementing the aliasing feature
- [LLVMdev] [lld] Implementing the aliasing feature
- [LLVMdev] [lld] Implementing the aliasing feature
- [LLVMdev] [lld] Atom object model refactoring.
- [LLVMdev] [lld] -emit-yaml doesnot contain linker added symbols specified with command line options