On Tue, Jan 8, 2013 at 8:56 PM, <shankare at codeaurora.org> wrote:> Hi Michael, > > Does ELF support aliasing ? > > How is the relationship captured in ELF symbol table, that one symbol is a > alias of another symbol ?It is not explicitly captured. It's an implicit relationship due to the symbols having the same address.> >> Note that __stdout_used is the last symbol in the .rodata section. >> This means that the reader assigns the data (16 bytes of 0) to >> __stdout_used. Because dummy_file and the other __stdx_used symbols >> come before it, they end up in the right place in the final file. > > Did you change the Reader too ?No. I just made another symbol to steal the actual content.> > The Reader doesnot allocate any space for __stdout_used. The size of the > current symbol = (value of next symbol - current symbol). In this case its > zero.__stdout_used is the last symbol at that address, so it gets the data. The hack was to make __stdout_used not get the data.> >> >> This works great until another object file provides a definition of >> __stdout_used. The weak definition of it gets totally removed, meaning >> so does the content for the other __stdx_used symbols. > > When the other object provides a definition for __stdout_used, the atom > gets the property of the other object which defines the atom isnt it, and > so as the ordinal too riht ? > > Couldnt follow how did the others move ?I'm not quite sure what you mean here.> > This is what I see with binutils/ld :- > > $cat 1.c > #include "stdio_impl.h" > > static FILE *const dummy_file = 0; > weak_alias(dummy_file, __stdin_used); > weak_alias(dummy_file, __stdout_used); > weak_alias(dummy_file, __stderr_used); > > $cat 2.c > int __stdout_used = 10; > $readelf -s 1.o | grep -E 'used|dummy_file' > 6: 0000000000000000 8 OBJECT LOCAL DEFAULT 4 dummy_file > 9: 0000000000000000 8 OBJECT WEAK DEFAULT 4 __stdin_used > 10: 0000000000000000 8 OBJECT WEAK DEFAULT 4 __stdout_used > 11: 0000000000000000 8 OBJECT WEAK DEFAULT 4 __stderr_used > $readelf -s 2.o | grep -E 'used|dummy_file' > 7: 0000000000000000 4 OBJECT GLOBAL DEFAULT 2 __stdout_used > $ld 1.o 2.o > ld: warning: cannot find entry symbol _start; defaulting to 00000000004000e8 > $readelf -s a.out | grep -E 'used|dummy_file' > 5: 00000000004000e8 8 OBJECT LOCAL DEFAULT 1 dummy_file > 7: 00000000006000f0 4 OBJECT GLOBAL DEFAULT 2 __stdout_used > 8: 00000000004000e8 8 OBJECT WEAK DEFAULT 1 __stdin_used > 13: 00000000004000e8 8 OBJECT WEAK DEFAULT 1 __stderr_used > > Thanks > > Shankar Easwaran >Yes, which is what we want. Currently we get a dummy_file, __stdin_used, __stderr_used all as 0 size. - Michael Spencer
> On Tue, Jan 8, 2013 at 8:56 PM, <shankare at codeaurora.org> wrote: >> Hi Michael, >> >> Does ELF support aliasing ? >> >> How is the relationship captured in ELF symbol table, that one symbol is >> a >> alias of another symbol ? > > It is not explicitly captured. It's an implicit relationship due to > the symbols having the same address.Got it.> >> >>> Note that __stdout_used is the last symbol in the .rodata section. >>> This means that the reader assigns the data (16 bytes of 0) to >>> __stdout_used. Because dummy_file and the other __stdx_used symbols >>> come before it, they end up in the right place in the final file. >> >> Did you change the Reader too ? > > No. I just made another symbol to steal the actual content.We could change the Reader so that if the symbol is the last symbol in the section and the symbol is weak, treat the size of the symbol differently.> >> >> The Reader doesnot allocate any space for __stdout_used. The size of the >> current symbol = (value of next symbol - current symbol). In this case >> its >> zero. > > __stdout_used is the last symbol at that address, so it gets the data. > The hack was to make __stdout_used not get the data.Got it. Thanks for explainining things.> >> >>> >>> This works great until another object file provides a definition of >>> __stdout_used. The weak definition of it gets totally removed, meaning >>> so does the content for the other __stdx_used symbols. >> >> When the other object provides a definition for __stdout_used, the atom >> gets the property of the other object which defines the atom isnt it, >> and >> so as the ordinal too riht ? >> >> Couldnt follow how did the others move ? > > I'm not quite sure what you mean here.Sorry for not making it clear. I was not sure how did the content of the other symbols change when another object file provided a definition of __stdout_used ? Thanks Shankar Easwaran
On Wed, Jan 9, 2013 at 6:07 AM, <shankare at codeaurora.org> wrote:>> On Tue, Jan 8, 2013 at 8:56 PM, <shankare at codeaurora.org> wrote: >>> Hi Michael, >>> >>> Does ELF support aliasing ? >>> >>> How is the relationship captured in ELF symbol table, that one symbol is >>> a >>> alias of another symbol ? >> >> It is not explicitly captured. It's an implicit relationship due to >> the symbols having the same address. > > Got it. > >> >>> >>>> Note that __stdout_used is the last symbol in the .rodata section. >>>> This means that the reader assigns the data (16 bytes of 0) to >>>> __stdout_used. Because dummy_file and the other __stdx_used symbols >>>> come before it, they end up in the right place in the final file. >>> >>> Did you change the Reader too ? >> >> No. I just made another symbol to steal the actual content. > We could change the Reader so that if the symbol is the last symbol in the > section and the symbol is weak, treat the size of the symbol differently.This doesn't only occur when the symbol is the last in the section. It occurs any time a weak symbol shares content with another.>> >>> >>> The Reader doesnot allocate any space for __stdout_used. The size of the >>> current symbol = (value of next symbol - current symbol). In this case >>> its >>> zero. >> >> __stdout_used is the last symbol at that address, so it gets the data. >> The hack was to make __stdout_used not get the data. > > Got it. Thanks for explainining things. > >> >>> >>>> >>>> This works great until another object file provides a definition of >>>> __stdout_used. The weak definition of it gets totally removed, meaning >>>> so does the content for the other __stdx_used symbols. >>> >>> When the other object provides a definition for __stdout_used, the atom >>> gets the property of the other object which defines the atom isnt it, >>> and >>> so as the ordinal too riht ? >>> >>> Couldnt follow how did the others move ? >> >> I'm not quite sure what you mean here. > > Sorry for not making it clear. I was not sure how did the content of the > other symbols change when another object file provided a definition of > __stdout_used ?Because __stdout_used in __stdio_exit.o was the only symbol with the 8 null bytes, when another object file defined a non weak version of __stdout_used, the __stdio_exit.o::__stdout_used was removed along with its 8 null bytes. The non-weak definition ends up in a different location.> > Thanks > > Shankar Easwaran >- Michael Spencer