From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2575 invoked by alias); 27 Jan 2009 17:53:21 -0000 Received: (qmail 2565 invoked by uid 22791); 27 Jan 2009 17:53:21 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_13,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Jan 2009 17:53:12 +0000 Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id n0RHrAcY007881 for ; Tue, 27 Jan 2009 09:53:10 -0800 Received: from yx-out-2324.google.com (yxj3.prod.google.com [10.190.3.67]) by zps76.corp.google.com with ESMTP id n0RHqtxk005626 for ; Tue, 27 Jan 2009 09:53:07 -0800 Received: by yx-out-2324.google.com with SMTP id 3so2489484yxj.3 for ; Tue, 27 Jan 2009 09:53:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.132.2 with SMTP id f2mr1135670wfd.168.1233078786782; Tue, 27 Jan 2009 09:53:06 -0800 (PST) In-Reply-To: <74fef6df0901270509s3d6d2075rb08989ea7e886823@mail.gmail.com> References: <74fef6df0901260724p188c5507x2cfa3a4283f6fd41@mail.gmail.com> <20090126154138.GA14406@caradoc.them.org> <8ac60eac0901260851o2a93a13di8a6b8c9cd4f8c15f@mail.gmail.com> <74fef6df0901270509s3d6d2075rb08989ea7e886823@mail.gmail.com> Date: Tue, 27 Jan 2009 17:53:00 -0000 Message-ID: <8ac60eac0901270953y5352df9bk8ffbccf5a84920f4@mail.gmail.com> Subject: Re: baffling assembly-level weirdness From: Paul Pluzhnikov To: Mathieu Lacage Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00182.txt.bz2 On Tue, Jan 27, 2009 at 5:09 AM, Mathieu Lacage 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 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