From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8015 invoked by alias); 21 Mar 2003 21:49:53 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 7991 invoked from network); 21 Mar 2003 21:49:52 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.160.55.131) by sources.redhat.com with SMTP; 21 Mar 2003 21:49:52 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id C9F73354C; Fri, 21 Mar 2003 13:49:51 -0800 (PST) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h2LLnpU20106; Fri, 21 Mar 2003 13:49:51 -0800 Date: Fri, 21 Mar 2003 22:26:00 -0000 Message-Id: <200303212149.h2LLnpU20106@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: sjmunroe@vnet.ibm.com Cc: libc-hacker@sources.redhat.com Subject: Re: chech-abi for PPC64 In-Reply-To: Steven Munroe's message of Friday, 21 March 2003 15:01:04 -0600 <3E7B7D90.4020807@us.ibm.com> Emacs: because one operating system isn't enough. X-SW-Source: 2003-03/txt/msg00065.txt.bz2 The discrepancy that is confounding abilist.awk is that these symbols do not have STT_OBJECT type, which produces "DO" in objdump output. Instead they have STT_NOTYPE, which produces "D". They have also been put into .sbss rather than .sdata. You are using gcc 3.3, right? I get similar results on my ppc32 build when I use gcc 3.3. (I have not tried gcc 3.3 on another platform lately.) I bet that if you try both 3.2 and 3.3 as in the following example from my ppc32 machine, you will see similar output: $ echo 'int x = 0;' | gcc -S -o - -x c - .file "" .globl x .section ".sdata","aw" .align 2 .type x,@object .size x,4 x: .long 0 .ident "GCC: (GNU) 3.2.3 20030316 (Debian prerelease)" $ echo 'int x = 0;' | gcc-3.3 -S -o - -x c - .file "" .globl x .globl x .section ".sbss","aw",@nobits .align 2 x: .zero 4 .size x, 4 .ident "GCC: (GNU) 3.3 20030315 (prerelease)" $ GCC 3.3 decides that since these variables are initialized to zero, they can go into .sbss instead of .sdata. I guess that's ok (saves a word of disk space and the overhead of reading it in, which adds up eventually). However, it fails to emit the .type directive (and emits .globl twice, which is harmless but obviously not intended). My gcc-3.3 does the same thing for the normal case of a bss symbol, i.e.: $ echo 'int x __attribute__((nocommon));' | gcc-3.3 -S -o - -x c - .file "" .globl x .globl x .section ".sbss","aw",@nobits .align 2 x: .zero 4 .size x, 4 .ident "GCC: (GNU) 3.3 20030315 (prerelease)" $ The missing type field is only catastrophic for a function symbol, but it probably creates other problems for variables. I'm declaring it a feature that abilist.awk is so anal about parsing the objdump output and caught this problem for us. Please report this as a GCC bug through appropriate channels. My last trivial example is probably the simplest one whose fix will be the right thing, but make sure the "int x = 0;" case produces the right output too. For the record, the expected output for either "int x = 0;" or "int x __attribute__((nocommon));" is: .file "" .globl x .section ".sbss","aw",@nobits .type x,@object .size x, 4 .align 2 x: .zero 4 .ident "GCC: (GNU) 3.3 20030315 (prerelease)" (though the .type and .size lines can be placed anywhere, it doesn't matter). I don't think we should do anything in libc to work around this while GCC gets fixed. GCC 3.2 is fine already, and 3.3 is not released yet. Thanks, Roland