Re: baffling assembly-level weirdness

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Tue, Jan 27, 2009 at 5:09 AM, Mathieu Lacage
<mathieu.lacage@gmail.com> wrote:

> 3) the main executable has a global stdout variable which is
> referenced by the code in the main binary and initialized by a
> R_386_COPY relocation:
> mathieu@mathieu-boulot:~/code/elf-loader$ readelf -s /bin/ls|grep stdout@
>    93: 0805e3c0     4 OBJECT  GLOBAL DEFAULT   25 stdout@GLIBC_2.0 (2)
> mathieu@mathieu-boulot:~/code/elf-loader$ readelf -r /bin/ls|grep 0805e3c0
> 0805e3c0  00005d05 R_386_COPY        0805e3c0   stdout
> which is expected to copy the value of the stdout symbol from the libc.so.6
...
> As a side-note, I really wonder why (3): none of the executables I
> link myself contain an stdout variable so, I am somewhat curious as to
> where this is coming from (I would expect each access to stdout from
> the main binary to directly reference the symbol from the libc through
> the GOT). But, well, next time.

Seems pretty normal to me:

$ cat t.c
#include <stdio.h>

int main()
{
    fprintf(stdout, "Hello\n");
    return 0;
}

$ /usr/bin/gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
...

$ /usr/bin/gcc t.c && readelf -s a.out | grep stdout
     5: 080495a0     4 OBJECT  GLOBAL DEFAULT   23 stdout@GLIBC_2.0 (2)
    75: 080495a0     4 OBJECT  GLOBAL DEFAULT   23 stdout@@GLIBC_2.0

$ readelf -r a.out | grep 080495a0
080495a0  00000505 R_386_COPY        080495a0   stdout

Cheers,
-- 
Paul Pluzhnikov