From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3959 invoked by alias); 29 Jan 2002 20:13:16 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 3913 invoked from network); 29 Jan 2002 20:13:14 -0000 Received: from unknown (HELO alonzo) (64.23.37.80) by sources.redhat.com with SMTP; 29 Jan 2002 20:13:14 -0000 Received: from megacz by alonzo with local (Exim 3.12 #1 (Debian)) id 16VeYe-0007E3-00 for ; Tue, 29 Jan 2002 12:08:44 -0800 To: binutils@sources.redhat.com Subject: behavior of "strip -N" [[ added an example ]] References: <86sn8pt4xk.fsf@megacz.com> From: Adam Megacz X-Home-Page: http://www.megacz.com/adam Organization: Myself Date: Tue, 29 Jan 2002 16:41:00 -0000 In-Reply-To: Adam Megacz's message of "29 Jan 2002 09:58:31 -0800" Message-ID: <86r8o8rkc4.fsf@megacz.com> User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-01/txt/msg00629.txt.bz2 Adam Megacz writes: > I've noticed that when I strip a global symbol using strip -N and then > link with --noinhibit-exec, the locations where that symbol's address > would have been written get a 0x0 instead. Here's a concrete example of what I'm talking about: megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-strip -g libgcj.a megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-objdump -r libgcj.a | grep -A4 \\[.text\$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev RELOCATION RECORDS FOR [.text$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev]: OFFSET TYPE VALUE 00000009 dir32 .data$_ZN4java2io19SyncFailedException6class$E 0000000e DISP32 __Jv_RegisterClass megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-strip -gN .data\$_ZN4java2io19SyncFailedException6class\$E libgcj.a megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-objdump -r libgcj.a | grep -A4 \\[.text\$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev RELOCATION RECORDS FOR [.text$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev]: OFFSET TYPE VALUE 00000009 dir32 __ZN4java2io19SyncFailedExceptionC1Ev 0000000e DISP32 __Jv_RegisterClass Note that the relocation record's symbol changed when I stripped out the section containing the target of the symbol (see the line starting with "00000009" in each instance of grep)! Shouldn't the relocation record retain the same value, which would be an undefined symbol? Can anybody explain this behavior? - a