[lld] Implementing the aliasing feature

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

Ping ?

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

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

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?

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.

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.

Another way to do wrapping (using malloc as the example) is to:
1) introduce (pre-Resolver) an atom (call it X) that is named __real_malloc and has references: 1)to undefined _malloc and 2)undefined __wrap_malloc.
2) add a Pass which get X and looks at the reference to finds what the two references now point to (malloc and __wrap_malloc). It then walks the whole graph and changes references that point to malloc to point to __wrap_malloc instead, and any references to __real_malloc to malloc.

Doesnt this imply that the alias atom is a zero sized atom ? 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 to , 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 ? 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

Doesnt this imply that the alias atom is a zero sized atom ?

Yes. That is what an alias is - another name for something. An alias has no content of its own. It is just an alternate name for something. What do you think alias means?


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.

This sounds like you mean “alias” to mean take one implementation and override another implementation (that has a different name).

-Nick

Yes. I think ELF could treat it as a Layout-Before reference too. This way Darwin can share the same functionality.

Thanks for the explanations, Nick.

Shankar Easwaran

Spoke too early. ELF still needs a special reference to implement __wrap. The wrapped function in the case of ELF always points to an atom whose size > 0 and is not a weak atom.

I was thinking of calling it a reference *Override* ?

Thanks

Shankar Easwaran