Re: chech-abi for PPC64

[Roland McGrath <roland@redhat.com>]

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   "<stdin>"
		.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   "<stdin>"
		.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   "<stdin>"
		.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   "<stdin>"
		.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