Re: chech-abi for PPC64

Re: chech-abi for PPC64

[Steven Munroe]

[-- Attachment #1: Type: text/plain, Size: 183 bytes --]

Roland writes:

 > Any lines in a .symlist file containing ? indicate that the
 > abilist.awk script did not fully grok the objdump output.
 > Please send your libc.dynsym file

Done

[-- Attachment #2: libc.dynsym.bz2 --]
[-- Type: application/octet-stream, Size: 27210 bytes --]

Re: chech-abi for PPC64

[Roland McGrath]

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

Re: chech-abi for PPC64

[Steve Munroe]

Roland McGrath writes:

> 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.)

Yes the tls/__thread support for ppc32/64 is only available in gcc-3.3+. 
I'll bring this up with Alan and Janis.

Thanks.

Re: chech-abi for PPC64

[Jakub Jelinek]

On Fri, Mar 21, 2003 at 04:26:17PM -0600, Steve Munroe wrote:
> Roland McGrath writes:
> 
> > 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.)
> 
> Yes the tls/__thread support for ppc32/64 is only available in gcc-3.3+. 
> I'll bring this up with Alan and Janis.

It will be soon available on gcc-3_2-rhl8-branch too.

	Jakub

Re: chech-abi for PPC64

[Steven Munroe]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

Sent this note yesterday but libc-hacker is picky about which version of 
me it accepted mail from... resending with the correct From: spelling.

Ok I ran the command:

  make -s update-abi update-abi-config='powerpc64-.*-linux.*'

and

  make -s update-abi update-abi-config='powerpc64-.*-linux.*/notls'

(as two separate builds -with-tls and -without-tls)

But when I run:

  make -sk check-abi

I see the following error:

--- -    2003-03-20 13:28:53.000000000 -0600
+++ /home/sjmunroe/work/build-23/libc.symlist    2003-03-20 
13:28:53.000000000 -0600
@@ -0,0 +1,12 @@
+in6addr_any GLIBC_2.3 g ? D .bss 0000000000000010
+__daylight GLIBC_2.3 g ? D .bss 0000000000000004
+__malloc_initialize_hook GLIBC_2.3 w ? D .bss 0000000000000008
+daylight GLIBC_2.3 w ? D .bss 0000000000000004
+_environ GLIBC_2.3 w ? D .bss 0000000000000008
+__environ GLIBC_2.3 g ? D .bss 0000000000000008
+__after_morecore_hook GLIBC_2.3 w ? D .bss 0000000000000008
+environ GLIBC_2.3 w ? D .bss 0000000000000008
+__fpu_control GLIBC_2.3 g ? D .bss 0000000000000004
+timezone GLIBC_2.3 w ? D .bss 0000000000000008
+__timezone GLIBC_2.3 g ? D .bss 0000000000000008
+__free_hook GLIBC_2.3 w ? D .bss 0000000000000008
make[2]: *** [check-abi-libc] Error 1
make[2]: Target `subdir_check-abi' not remade because of errors.
make[1]: *** [elf/subdir_check-abi] Error 2
make[1]: Target `check-abi' not remade because of errors.
make: *** [check-abi] Error 2

This all seems to be out of arch indepentant code. For example 
time.tzset.c does declare __daylight and __timezone. Do I (PPC64) need 
to do something about this?

[-- Attachment #2: ppc64-abilist-20030319.tgz --]
[-- Type: application/x-compressed, Size: 30502 bytes --]

Re: chech-abi for PPC64

[Roland McGrath]

Any lines in a .symlist file containing ? indicate that the abilist.awk
script did not fully grok the objdump output.   Please send your
libc.dynsym file (which is just objdump --dynamic-syms libc.so.6).


Thanks,
Roland