This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |