[LLVMdev] [lld] Implementing the aliasing feature
Shankar Easwaran
shankare at codeaurora.org
Fri Sep 13 16:16:41 PDT 2013
On 9/13/2013 6:06 PM, Nick Kledzik wrote:
> On Sep 13, 2013, at 3:35 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>> This would work only if an alias is another name for the same symbol(weak symbols).
> I don’t know what that means. Can you clarify?
Doesnt this imply that the alias atom is a zero sized atom ?
>> If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work.
> That is the exact scenario I think it *will* work in. What do you think won’t work.
If its a non zero sized atom, like for example :-
definedatoms:
- name : fna
size : 4
...
...
definedatoms:
- name: fnb
size: 4
If I alias the atom, and add a layoutBefore from *fna* to *fnb*, fnb is
going to have a seperate virtualaddress from fna.
But you essentially wanted fna, fnb to have the same virtual address right ?
Am I misreading something that you said ?
>
>
>> 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.
> I don’t see how those steps will achieve wrapping functionality. Say you are wrapping malloc. There will be a malloc seen at build time from libc, and all references to malloc will bind to it. Adding alternate names won’t stop that binding.
Yes, thats how ld is behaving, if I have the the function in my .o's, it
doesnot override.
For example :-
#include <stdio.h>
int myfn() {
return 0;
}
void __wrap_myfn()
{
printf("Hello World\n");
}
int main() {
myfn();
return 0;
}
$gcc wrap.c -Wl,--wrap,fn
$./a.out
$
Thanks
Shankar Easwaran
--
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-dev/attachments/20130913/743c1727/attachment.html>
More information about the llvm-dev
mailing list