gcc4.4.1 related doubt

gcc4.4.1 related doubt

[trisha yad]

H all,


I am using gcc4.4.1.

When iam compiling  test program if i don't use "-fno-optimize-sibling-calls" it
won't generate  T.<num> symbols ,but in case  of Kernel build even though
 i won't use "-fno-optimize-sibling-calls" it is generating T.<num>.

Is there any way to prevent gcc(gcc4.4.1) from generating T.<num> in
case kernel build ?


On Wed, Mar 24, 2010 at 1:07 PM, James Kehl <jamesk@edmi.com.au> wrote:
>> -----Original Message-----
>> From: 42Bastian [mailto:list-bastian.schick@sciopta.com]
>> Sent: Wednesday, 24 March 2010 5:30 PM
>> To: trisha yad
>> Cc: arm-gnu@codesourcery.com
>> Subject: Re: [arm-gnu] bug in
>>
>> Am 24.03.2010 08:07, schrieb trisha yad:
>>
>> > Actually iam compiling kernel code for arm processor, so i need to
> use
>> > -O2 flag, so can't use -O0 flag,
>>
>> Why ?
>>
>
> Off the top of my head, the Linux kernel relies heavily on inlining of
> functions from header files.
>
> I think there are quite a few functions that are never given as
> out-of-line versions. If you compile with -O0, the link fails due to
> these 'missing' functions.
>
> Of course, I could be wrong - it's been a while since I tried compiling
> a kernel with -O0 :)
>
> J
>
>

Re: gcc4.4.1 related doubt

[Ian Lance Taylor]

trisha yad <trisha1march@gmail.com> writes:

> When iam compiling  test program if i don't use "-fno-optimize-sibling-calls" it
> won't generate  T.<num> symbols ,but in case  of Kernel build even though
>  i won't use "-fno-optimize-sibling-calls" it is generating T.<num>.
>
> Is there any way to prevent gcc(gcc4.4.1) from generating T.<num> in
> case kernel build ?

I don't know what T.<num> symbols are.  Give us a small,
self-contained, example.  Show exactly what you did, exactly what you
got, and what you expected to get instead.

Ian

Re: gcc4.4.1 related doubt

[David Daney]

On 03/24/2010 07:34 AM, Ian Lance Taylor wrote:
> trisha yad<trisha1march@gmail.com>  writes:
>
>> When iam compiling  test program if i don't use "-fno-optimize-sibling-calls" it
>> won't generate  T.<num>  symbols ,but in case  of Kernel build even though
>>   i won't use "-fno-optimize-sibling-calls" it is generating T.<num>.

Your problem is caused by bugs in the Linux kernel build system.  At one 
point someone thought the presence of these symbols indicated a bug in 
the kernel source code, and the build scripts explicitly looked for them 
and flagged them.  With more recent kernels, it was realized that this 
flagging is improper and it was removed.

I would suggest that you fix you fix your kernel build scripts rather 
than trying to work around their faulty behavior.


>>
>> Is there any way to prevent gcc(gcc4.4.1) from generating T.<num>  in
>> case kernel build ?
>
> I don't know what T.<num>  symbols are.

I had this issue at one point.  I forget what causes these symbols to be 
emitted, but I do know that it is normal and not a compiler bug.

David Daney

Re: gcc4.4.1 related doubt

[trisha yad]

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

thanks for your reply


I am attaching one sample program.

1. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O0 test.c
2. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
arm-linux-gnueabi-nm of O0 is log1
arm-linux-gnueabi-nm of O2 is log


I am attaching o/p of command using option --save-temps i.e in file test.s
arm-linux-gnueabi-gcc -fno-optimize-sibling-calls --save-temps -O2 test.c

arm-linux-gnueabi-as -v
GNU assembler version 2.19.51 (arm-linux-gnueabi) using BFD version
(Sourcery G++ Lite 2009q1-203) 2.19.51.20090205

_-----------------------------------------------------------------------------------------------------------------------------
arm-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with:
/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/src/gcc-4.4/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --enable-extra-sgxxlite-multilibs
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}'
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion='Sourcery G++ Lite 2009q1-203'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/
--disable-nls --prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-linux-gnueabi/libc
--with-build-sysroot=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/install/arm-linux-gnueabi/libc
--with-gmp=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/obj/host-libs-2009q1-203-arm-linux-gnueabi-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/obj/host-libs-2009q1-203-arm-linux-gnueabi-i686-pc-linux-gnu/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/install/arm-linux-gnueabi/bin
--with-build-time-tools=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/install/arm-linux-gnueabi/bin
--with-interwork --with-cpu=cortex-a9 --with-arch=armv7-a
--with-mode=arm --with-tune=cortex-a9 --with-fpu=vfp3
--with-float=softfp
Thread model: posix
gcc version 4.4.1 (Sourcery G++ Lite 2009q1-203)
--------------------------------------------------------------------------------------------------------------------------------------


On Thu, Mar 25, 2010 at 7:21 PM, Ian Lance Taylor <iant@google.com> wrote:
> trisha yad <trisha1march@gmail.com> writes:
>
>> I am sending you simple test program.
>>
>> I run following command
>> arm-linux-gnueabi-gcc  --save-temps  -O0  main.c
>> arm-linux-gnueabi-gcc  --save-temps  -O2  main.c (Function name disappear)
>
> Please reply to the mailing list, not just to me.  Thanks.
>
> I don't see any T. symbols in the assembly files that you sent.
> Presumably the assembler is inserting these symbols.  Although, when I
> ran a recent version of gas, it did not do so.  What assembler are you
> using?
>
> I would guess that these are ARM mapping symbols.  Why are they a
> problem?
>
> Ian
>

[-- Attachment #2: test.c --]
[-- Type: application/octet-stream, Size: 244 bytes --]

#include<stdio.h>

static void ABC(int);
static void BCD(int);

main()
{
int k=0;
ABC(234);
printf("%d",k);
ABC(2312);
}


static void ABC(int i)
{
int k=234;
k=k+i;
BCD(234);
}


static void BCD(int i)
{
int k1=234;
ABC(86);
k1=k1+i+16834;

}

[-- Attachment #3: log --]
[-- Type: application/octet-stream, Size: 1052 bytes --]

0000844c t T.12
0001069c d _DYNAMIC
0001078c d _GLOBAL_OFFSET_TABLE_
00008540 R _IO_stdin_used
         w _Jv_RegisterClasses
0000868c r __FRAME_END__
00010698 d __JCR_END__
00010698 d __JCR_LIST__
         U __aeabi_unwind_cpp_pr0@@GCC_3.5
         U __aeabi_unwind_cpp_pr1@@GCC_3.5
000107b8 A __bss_end__
000107b4 A __bss_start
000107b4 A __bss_start__
000107ac D __data_start
000083fc t __do_global_dtors_aux
00010694 t __do_global_dtors_aux_fini_array_entry
000107b0 D __dso_handle
000107b8 A __end__
000085a0 A __exidx_end
00008560 A __exidx_start
00010690 t __frame_dummy_init_array_entry
         w __gmon_start__
00010694 t __init_array_end
00010690 t __init_array_start
00008468 T __libc_csu_fini
0000846c T __libc_csu_init
         U __libc_start_main@@GLIBC_2.4
000107b8 A _bss_end__
000107b4 A _edata
000107b8 A _end
00008538 T _fini
00008350 T _init
000083a0 T _start
         U abort@@GLIBC_2.4
000083d8 t call_gmon_start
000107b4 b completed.6039
000107ac W data_start
0000841c t frame_dummy
00008450 T main
         U printf@@GLIBC_2.4

[-- Attachment #4: log1 --]
[-- Type: application/octet-stream, Size: 1066 bytes --]

0000848c t ABC
000084c4 t BCD
00010784 d _DYNAMIC
00010874 d _GLOBAL_OFFSET_TABLE_
000085dc R _IO_stdin_used
         w _Jv_RegisterClasses
00008774 r __FRAME_END__
00010780 d __JCR_END__
00010780 d __JCR_LIST__
         U __aeabi_unwind_cpp_pr0@@GCC_3.5
         U __aeabi_unwind_cpp_pr1@@GCC_3.5
000108a0 A __bss_end__
0001089c A __bss_start
0001089c A __bss_start__
00010894 D __data_start
000083fc t __do_global_dtors_aux
0001077c t __do_global_dtors_aux_fini_array_entry
00010898 D __dso_handle
000108a0 A __end__
0000865c A __exidx_end
00008614 A __exidx_start
00010778 t __frame_dummy_init_array_entry
         w __gmon_start__
0001077c t __init_array_end
00010778 t __init_array_start
00008504 T __libc_csu_fini
00008508 T __libc_csu_init
         U __libc_start_main@@GLIBC_2.4
000108a0 A _bss_end__
0001089c A _edata
000108a0 A _end
000085d4 T _fini
00008350 T _init
000083a0 T _start
         U abort@@GLIBC_2.4
000083d8 t call_gmon_start
0001089c b completed.6039
00010894 W data_start
0000841c t frame_dummy
0000844c T main
         U printf@@GLIBC_2.4

[-- Attachment #5: test.s --]
[-- Type: application/octet-stream, Size: 1079 bytes --]

	.arch armv7-a
	.eabi_attribute 27, 3
	.fpu vfp3
	.eabi_attribute 20, 1
	.eabi_attribute 21, 1
	.eabi_attribute 23, 3
	.eabi_attribute 24, 1
	.eabi_attribute 25, 1
	.eabi_attribute 26, 2
	.eabi_attribute 30, 2
	.eabi_attribute 18, 4
	.file	"test.c"
	.text
	.align	2
	.type	T.12, %function
T.12:
	.fnstart
.LFB14:
	.cfi_startproc
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	bx	lr
	.cfi_endproc
.LFE14:
	.fnend
	.size	T.12, .-T.12
	.align	2
	.global	main
	.type	main, %function
main:
	.fnstart
.LFB11:
	.cfi_startproc
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	stmfd	sp!, {r3, lr}
	.save {r3, lr}
	.cfi_def_cfa_offset 8
	movw	r0, #:lower16:.LC0
	mov	r1, #0
	movt	r0, #:upper16:.LC0
	.cfi_offset 14, -4
	.cfi_offset 3, -8
	bl	printf
	ldmfd	sp!, {r3, pc}
	.cfi_endproc
.LFE11:
	.fnend
	.size	main, .-main
	.section	.rodata.str1.4,"aMS",%progbits,1
	.align	2
.LC0:
	.ascii	"%d\000"
	.ident	"GCC: (Sourcery G++ Lite 2009q1-203) 4.4.1"
	.section	.note.GNU-stack,"",%progbits

[-- Attachment #6: test.o --]
[-- Type: application/octet-stream, Size: 1628 bytes --]

Re: gcc4.4.1 related doubt

[trisha yad]

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

thanks for your reply


I am attaching one sample program.

1. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O0 test.c
2. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
arm-linux-gnueabi-nm of O0 is log1
arm-linux-gnueabi-nm of O2 is log


I am attaching o/p of command using option --save-temps i.e in file test.s
arm-linux-gnueabi-gcc -fno-optimize-sibling-calls --save-temps -O2 test.c

arm-linux-gnueabi-as -v
GNU assembler version 2.19.51 (arm-linux-gnueabi) using BFD version
(Sourcery G++ Lite 2009q1-203) 2.19.51.20090205

_-----------------------------------------------------------------------------------------------------------------------------
arm-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with:
/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/src/gcc-4.4/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --enable-extra-sgxxlite-multilibs
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}'
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion='Sourcery G++ Lite 2009q1-203'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/
--disable-nls --prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-linux-gnueabi/libc
--with-build-sysroot=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/install/arm-linux-gnueabi/libc
--with-gmp=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/obj/host-libs-2009q1-203-arm-linux-gnueabi-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/obj/host-libs-2009q1-203-arm-linux-gnueabi-i686-pc-linux-gnu/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/install/arm-linux-gnueabi/bin
--with-build-time-tools=/scratch/mitchell/builds/4.4-arm-linux-gnueabi-respin/lite/install/arm-linux-gnueabi/bin
--with-interwork --with-cpu=cortex-a9 --with-arch=armv7-a
--with-mode=arm --with-tune=cortex-a9 --with-fpu=vfp3
--with-float=softfp
Thread model: posix
gcc version 4.4.1 (Sourcery G++ Lite 2009q1-203)
--------------------------------------------------------------------------------------------------------------------------------------


On Thu, Mar 25, 2010 at 7:21 PM, Ian Lance Taylor <iant@google.com> wrote:
> trisha yad <trisha1march@gmail.com> writes:
>
>> I am sending you simple test program.
>>
>> I run following command
>> arm-linux-gnueabi-gcc  --save-temps  -O0  main.c
>> arm-linux-gnueabi-gcc  --save-temps  -O2  main.c (Function name disappear)
>
> Please reply to the mailing list, not just to me.  Thanks.
>
> I don't see any T. symbols in the assembly files that you sent.
> Presumably the assembler is inserting these symbols.  Although, when I
> ran a recent version of gas, it did not do so.  What assembler are you
> using?
>
> I would guess that these are ARM mapping symbols.  Why are they a
> problem?
>
> Ian
>

[-- Attachment #2: test.c --]
[-- Type: application/octet-stream, Size: 244 bytes --]

#include<stdio.h>

static void ABC(int);
static void BCD(int);

main()
{
int k=0;
ABC(234);
printf("%d",k);
ABC(2312);
}


static void ABC(int i)
{
int k=234;
k=k+i;
BCD(234);
}


static void BCD(int i)
{
int k1=234;
ABC(86);
k1=k1+i+16834;

}

[-- Attachment #3: log --]
[-- Type: application/octet-stream, Size: 1052 bytes --]

0000844c t T.12
0001069c d _DYNAMIC
0001078c d _GLOBAL_OFFSET_TABLE_
00008540 R _IO_stdin_used
         w _Jv_RegisterClasses
0000868c r __FRAME_END__
00010698 d __JCR_END__
00010698 d __JCR_LIST__
         U __aeabi_unwind_cpp_pr0@@GCC_3.5
         U __aeabi_unwind_cpp_pr1@@GCC_3.5
000107b8 A __bss_end__
000107b4 A __bss_start
000107b4 A __bss_start__
000107ac D __data_start
000083fc t __do_global_dtors_aux
00010694 t __do_global_dtors_aux_fini_array_entry
000107b0 D __dso_handle
000107b8 A __end__
000085a0 A __exidx_end
00008560 A __exidx_start
00010690 t __frame_dummy_init_array_entry
         w __gmon_start__
00010694 t __init_array_end
00010690 t __init_array_start
00008468 T __libc_csu_fini
0000846c T __libc_csu_init
         U __libc_start_main@@GLIBC_2.4
000107b8 A _bss_end__
000107b4 A _edata
000107b8 A _end
00008538 T _fini
00008350 T _init
000083a0 T _start
         U abort@@GLIBC_2.4
000083d8 t call_gmon_start
000107b4 b completed.6039
000107ac W data_start
0000841c t frame_dummy
00008450 T main
         U printf@@GLIBC_2.4

[-- Attachment #4: log1 --]
[-- Type: application/octet-stream, Size: 1066 bytes --]

0000848c t ABC
000084c4 t BCD
00010784 d _DYNAMIC
00010874 d _GLOBAL_OFFSET_TABLE_
000085dc R _IO_stdin_used
         w _Jv_RegisterClasses
00008774 r __FRAME_END__
00010780 d __JCR_END__
00010780 d __JCR_LIST__
         U __aeabi_unwind_cpp_pr0@@GCC_3.5
         U __aeabi_unwind_cpp_pr1@@GCC_3.5
000108a0 A __bss_end__
0001089c A __bss_start
0001089c A __bss_start__
00010894 D __data_start
000083fc t __do_global_dtors_aux
0001077c t __do_global_dtors_aux_fini_array_entry
00010898 D __dso_handle
000108a0 A __end__
0000865c A __exidx_end
00008614 A __exidx_start
00010778 t __frame_dummy_init_array_entry
         w __gmon_start__
0001077c t __init_array_end
00010778 t __init_array_start
00008504 T __libc_csu_fini
00008508 T __libc_csu_init
         U __libc_start_main@@GLIBC_2.4
000108a0 A _bss_end__
0001089c A _edata
000108a0 A _end
000085d4 T _fini
00008350 T _init
000083a0 T _start
         U abort@@GLIBC_2.4
000083d8 t call_gmon_start
0001089c b completed.6039
00010894 W data_start
0000841c t frame_dummy
0000844c T main
         U printf@@GLIBC_2.4

[-- Attachment #5: test.s --]
[-- Type: application/octet-stream, Size: 1079 bytes --]

	.arch armv7-a
	.eabi_attribute 27, 3
	.fpu vfp3
	.eabi_attribute 20, 1
	.eabi_attribute 21, 1
	.eabi_attribute 23, 3
	.eabi_attribute 24, 1
	.eabi_attribute 25, 1
	.eabi_attribute 26, 2
	.eabi_attribute 30, 2
	.eabi_attribute 18, 4
	.file	"test.c"
	.text
	.align	2
	.type	T.12, %function
T.12:
	.fnstart
.LFB14:
	.cfi_startproc
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	bx	lr
	.cfi_endproc
.LFE14:
	.fnend
	.size	T.12, .-T.12
	.align	2
	.global	main
	.type	main, %function
main:
	.fnstart
.LFB11:
	.cfi_startproc
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	stmfd	sp!, {r3, lr}
	.save {r3, lr}
	.cfi_def_cfa_offset 8
	movw	r0, #:lower16:.LC0
	mov	r1, #0
	movt	r0, #:upper16:.LC0
	.cfi_offset 14, -4
	.cfi_offset 3, -8
	bl	printf
	ldmfd	sp!, {r3, pc}
	.cfi_endproc
.LFE11:
	.fnend
	.size	main, .-main
	.section	.rodata.str1.4,"aMS",%progbits,1
	.align	2
.LC0:
	.ascii	"%d\000"
	.ident	"GCC: (Sourcery G++ Lite 2009q1-203) 4.4.1"
	.section	.note.GNU-stack,"",%progbits

[-- Attachment #6: test.o --]
[-- Type: application/octet-stream, Size: 1628 bytes --]

Re: gcc4.4.1 related doubt

[Ian Lance Taylor]

trisha yad <trisha1march@gmail.com> writes:

> I am attaching one sample program.
>
> 1. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O0 test.c
> 2. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
> arm-linux-gnueabi-nm of O0 is log1
> arm-linux-gnueabi-nm of O2 is log
>
>
> I am attaching o/p of command using option --save-temps i.e in file test.s
> arm-linux-gnueabi-gcc -fno-optimize-sibling-calls --save-temps -O2 test.c

I don't understand how the .c file you showed can produce the .s file
that you showed.  In the .c file, main calls ABC.  In the .s file, it
does not.  I don't see how the optimizer could remove that call.

I do see the T.12 symbol in the assembler source.  However, I don't
know where it came from.  I don't see when I compile your C file with
a recent ARM gcc.

Can you explain why the T.12 symbol is a problem?

Ian

Re: gcc4.4.1 related doubt

[Jie Zhang]

On 03/26/2010 01:13 AM, Ian Lance Taylor wrote:
 > trisha yad<trisha1march@gmail.com>  writes:
 >
 >> I am attaching one sample program.
 >>
 >> 1. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O0 test.c
 >> 2. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
 >> arm-linux-gnueabi-nm of O0 is log1
 >> arm-linux-gnueabi-nm of O2 is log
 >>
 >>
 >> I am attaching o/p of command using option --save-temps i.e in file 
test.s
 >> arm-linux-gnueabi-gcc -fno-optimize-sibling-calls --save-temps -O2 
test.c
 >
 > I don't understand how the .c file you showed can produce the .s file
 > that you showed.  In the .c file, main calls ABC.  In the .s file, it
 > does not.  I don't see how the optimizer could remove that call.
 >
I cannot reproduce this issue from the attached source file either.

 > I do see the T.12 symbol in the assembler source.  However, I don't
 > know where it came from.  I don't see when I compile your C file with
 > a recent ARM gcc.
 >
It might come from compiler instantiating a function, i.e. T.12 is a 
clone of a function but with some parameters instantiated. Just my guess.

 > Can you explain why the T.12 symbol is a problem?
 >
I think it should not be a problem. T.12 is a local symbol, it can be 
stripped by strip with appropriate options.


-- 
Jie Zhang
CodeSourcery
(650) 331-3385 x735

gcc4.4.1 related doubt

[trisha yad]

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

Hi Jie,


Thanks for your response.

I have downloaded cross toolchain from codesourcercy site.(Download
Sourcery G++ Lite 2009q3-67 )

http://www.codesourcery.com/sgpp/lite/arm/portal/subscription3057

arm-2009q3/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with:
/scratch/julian/2009q3-respin-linux-lite/src/gcc-4.4/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs --with-arch=armv5te --with-gnu-as
--with-gnu-ld --with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--disable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery G++ Lite 2009q3-67'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/
--disable-nls --prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/julian/2009q3-respin-linux-lite/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/julian/2009q3-respin-linux-lite/obj/host-libs-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/julian/2009q3-respin-linux-lite/obj/host-libs-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-ppl=/scratch/julian/2009q3-respin-linux-lite/obj/host-libs-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm' --with-cloog=/scratch/julian/2009q3-respin-linux-lite/obj/host-libs-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/julian/2009q3-respin-linux-lite/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/julian/2009q3-respin-linux-lite/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67)


I have Build 2.6.30 kernel for ARM
and i am attaching my System.map file for your reference.


also i am able to reproduce attached result when i build my attach
program using below options.

arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
I can see Function name  Convert to
0000842c t T.12


But If i give O0 Flag when Building then
0000834c t $d
00008470 t ABC
000084a8 t BCD


I want to Build my kernel with O2 flag. Will you please provide some
flag except 'O0' which disable this optimization.

I have not check o/p of binary with gdb. Is GDB will have any issue
with this type of optimization ?


On Fri, Mar 26, 2010 at 12:18 PM, Jie Zhang <jie@codesourcery.com> wrote:
> On 03/26/2010 01:13 AM, Ian Lance Taylor wrote:
>> trisha yad<trisha1march@gmail.com>  writes:
>>
>>> I am attaching one sample program.
>>>
>>> 1. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O0 test.c
>>> 2. arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
>>> arm-linux-gnueabi-nm of O0 is log1
>>> arm-linux-gnueabi-nm of O2 is log
>>>
>>>
>>> I am attaching o/p of command using option --save-temps i.e in file
>>> test.s
>>> arm-linux-gnueabi-gcc -fno-optimize-sibling-calls --save-temps -O2 test.c
>>
>> I don't understand how the .c file you showed can produce the .s file
>> that you showed.  In the .c file, main calls ABC.  In the .s file, it
>> does not.  I don't see how the optimizer could remove that call.
>>
> I cannot reproduce this issue from the attached source file either.
>
>> I do see the T.12 symbol in the assembler source.  However, I don't
>> know where it came from.  I don't see when I compile your C file with
>> a recent ARM gcc.
>>
> It might come from compiler instantiating a function, i.e. T.12 is a clone
> of a function but with some parameters instantiated. Just my guess.
>
>> Can you explain why the T.12 symbol is a problem?
>>
> I think it should not be a problem. T.12 is a local symbol, it can be
> stripped by strip with appropriate options.
>
>
> --
> Jie Zhang
> CodeSourcery
> (650) 331-3385 x735
>
>

[-- Attachment #2: System.map.tgz --]
[-- Type: application/x-gzip, Size: 255051 bytes --]

Re: gcc4.4.1 related doubt

[Jie Zhang]

On 03/26/2010 08:25 PM, trisha yad wrote:
> I have downloaded cross toolchain from codesourcercy site.(Download
> Sourcery G++ Lite 2009q3-67 )
>
gcc-help is not a good place to ask questions about non-FSF toolchains. 
For GCC provided by CodeSourcery, you'd better ask your questions on 
CodeSourcery's mailing lists or its support portal.

>
> I want to Build my kernel with O2 flag. Will you please provide some
> flag except 'O0' which disable this optimization.
>
I still don't know why you don't want those symbols in your binary.

> I have not check o/p of binary with gdb. Is GDB will have any issue
> with this type of optimization ?
>
I don't know.


-- 
Jie Zhang
CodeSourcery
(650) 331-3385 x735

Re: FW: gcc4.4.1 related doubt

[Ian Lance Taylor]

trisha yad <trisha1march@gmail.com> writes:

> arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
> I can see Function name  Convert to
> 0000842c t T.12

You still haven't explained what is wrong with that symbol.  Why does
it matter?

> I want to Build my kernel with O2 flag. Will you please provide some
> flag except 'O0' which disable this optimization.

Try -fno-ipa-cp.

Ian

Re: FW: gcc4.4.1 related doubt

[Jie Zhang]

On 03/27/2010 11:51 AM, trisha yad wrote:
> Hi all,
>
> Yes David if i build my kernel with GCC 4.3.3 there is no issue.
> But since we have to use Cortex a9 support, which is in GCC 4.4 so
> that is reason for using current tool chain.
>
> I also try to build Linux 2.6.33, and got the same problem.
>
> I could not find a clue to get correct symbols.
>
Does -fno-ipa-cp work for you, as Ian suggested?


Jie

Re: FW: gcc4.4.1 related doubt

[trisha yad]

Hi all,

Yes David if i build my kernel with GCC 4.3.3 there is no issue.
But since we have to use Cortex a9 support, which is in GCC 4.4 so
that is reason for using current tool chain.

I also try to build Linux 2.6.33, and got the same problem.

I could not find a clue to get correct symbols.

Kind regards
trisha


On Sat, Mar 27, 2010 at 12:08 AM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 03/26/2010 10:27 AM, Ian Lance Taylor wrote:
>>
>> trisha yad<trisha1march@gmail.com>  writes:
>>
>>> arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
>>> I can see Function name  Convert to
>>> 0000842c t T.12
>>
>> You still haven't explained what is wrong with that symbol.  Why does
>> it matter?
>
> I thought I already said this, but here it is again:
>
> Some broken Linux kernel build scripts flag the presence of these symbols a
> something very bad.  If you try building a kernel containing these scripts,
> you might be lead to think that the end of the world is near.
>
> Obviously the way to fix the problem is to change GCC so it doesn't trigger
> the emission of these messages in the defective kernels. :-)
>
>
> David Daney
>

Re: FW: gcc4.4.1 related doubt

[trisha yad]

Hi all,

thanks everybody for giving me great help. So I use the flag as
suggested by Ian i.e   -fno-ipa-cp, now i am not getting any symbol
T.XXX.

will you please give me some reason behind this flag, need and use ?

Kind regards
Trisha



On Sat, Mar 27, 2010 at 9:28 AM, Jie Zhang <jie@codesourcery.com> wrote:
> On 03/27/2010 11:51 AM, trisha yad wrote:
>>
>> Hi all,
>>
>> Yes David if i build my kernel with GCC 4.3.3 there is no issue.
>> But since we have to use Cortex a9 support, which is in GCC 4.4 so
>> that is reason for using current tool chain.
>>
>> I also try to build Linux 2.6.33, and got the same problem.
>>
>> I could not find a clue to get correct symbols.
>>
> Does -fno-ipa-cp work for you, as Ian suggested?
>
>
> Jie
>

Re: FW: gcc4.4.1 related doubt

[Jie Zhang]

On 03/27/2010 05:15 PM, trisha yad wrote:
> Hi all,
>
> thanks everybody for giving me great help. So I use the flag as
> suggested by Ian i.e   -fno-ipa-cp, now i am not getting any symbol
> T.XXX.
>
> will you please give me some reason behind this flag, need and use ?
>
See -fipa-cp in GCC manual of your GCC version.

Jie

Re: FW: gcc4.4.1 related doubt

[trisha yad]

I am the colleague of  OP.

Let me clarify few things which OP forgot to mention. ( Get a cup of
coffee, Trisha ! )   :

a)  Our problem :   As discussed,  some of the function symbol names
appear  as  T.XXX in the  symbol-section  of  Linux kernel ELF file.
The build  is OK  and  there is no  script-fail  issue here ( as Mr
Daney seems to think. )

Our company wants us to  fix this problem.  We dont  want to "remove"
these symbols.    Instead  , we want that  these symbols  should
appear with the original  function-names which they represent.

For example, if  there is  a  kernel-fault  occurring  near/after
T.XXX ,  we  want the correct function-name to get displayed in
backtrace.

We cannot change the toolchain version. We need Cortex support.

Also , we dont  think  there is any connection to inlining here.
Looking  at the objdump shows that  T.XXX is  a normal function  which
gets called
with the  usual  bl  call in  ARM.

                         thanks


On Mon, Mar 29, 2010 at 11:09 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 03/26/2010 08:51 PM, trisha yad wrote:
>>
>> Hi all,
>>
>> Yes David if i build my kernel with GCC 4.3.3 there is no issue.
>> But since we have to use Cortex a9 support, which is in GCC 4.4 so
>> that is reason for using current tool chain.
>>
>> I also try to build Linux 2.6.33, and got the same problem.
>>
>
> Look at the error messages you are getting.  Take the part of the message
> that doesn't contain a symbol name or other text that varies. Grep all the
> kernel sources for that text (especially the scripts directory).  That
> should show you where the messages that are upsetting you are generated.
>  Then do one of the following:
>
> 1) Delete the lines of the scripts that generate the message.  After
>   doing that you should be happy.
>
> 2) Share with us the exact location in the kernel sources the messages
>   are generated.
>
>   2a) Someone might analyze the situation further and help you.
>   2b) Delete the lines of the scripts after being assured that they
>       shouldn't be there.  Now you should be happy.
>
>
>> I could not find a clue to get correct symbols.
>>
>> Kind regards
>> trisha
>>
>>
>> On Sat, Mar 27, 2010 at 12:08 AM, David Daney<ddaney@caviumnetworks.com>
>>  wrote:
>>>
>>> On 03/26/2010 10:27 AM, Ian Lance Taylor wrote:
>>>>
>>>> trisha yad<trisha1march@gmail.com>    writes:
>>>>
>>>>> arm-linux-gnueabi-gcc -fno-optimize-sibling-calls -O2 test.c
>>>>> I can see Function name  Convert to
>>>>> 0000842c t T.12
>>>>
>>>> You still haven't explained what is wrong with that symbol.  Why does
>>>> it matter?
>>>
>>> I thought I already said this, but here it is again:
>>>
>>> Some broken Linux kernel build scripts flag the presence of these symbols
>>> a
>>> something very bad.  If you try building a kernel containing these
>>> scripts,
>>> you might be lead to think that the end of the world is near.
>>>
>>> Obviously the way to fix the problem is to change GCC so it doesn't
>>> trigger
>>> the emission of these messages in the defective kernels. :-)
>>>
>>>
>>> David Daney
>>>
>>
>
>

Re: FW: gcc4.4.1 related doubt

[Ian Lance Taylor]

trisha yad <trisha1march@gmail.com> writes:

> a)  Our problem :   As discussed,  some of the function symbol names
> appear  as  T.XXX in the  symbol-section  of  Linux kernel ELF file.
> The build  is OK  and  there is no  script-fail  issue here ( as Mr
> Daney seems to think. )
>
> Our company wants us to  fix this problem.  We dont  want to "remove"
> these symbols.    Instead  , we want that  these symbols  should
> appear with the original  function-names which they represent.
>
> For example, if  there is  a  kernel-fault  occurring  near/after
> T.XXX ,  we  want the correct function-name to get displayed in
> backtrace.
>
> We cannot change the toolchain version. We need Cortex support.
>
> Also , we dont  think  there is any connection to inlining here.
> Looking  at the objdump shows that  T.XXX is  a normal function  which
> gets called
> with the  usual  bl  call in  ARM.

So, you are asking how to disable the generation of the T.XXX
functions?  Those functions are clones created for better performance.
If you give us a small test case showing the T.XXX function being
created, we will tell you the command line option which will disable
that specific optimization.

By the way, at least with mainline -fno-ipa-cp-clone is a better
approach than -fno-ipa-cp, since it does permit some optimizations.

And, for what it's worth, the names used for clone functions in
mainline gcc do include the name of the original function.

Ian

Re: gcc4.4.1 related doubt

[trisha yad]

On Thu, Apr 15, 2010 at 7:46 PM, Ian Lance Taylor <iant@google.com> wrote:
> trisha yad <trisha1march@gmail.com> writes:
>
>> This is regarding issue of  -fno-ipa-cp on code sourcercy 2009q3-67.
>> We discuss this on mailing list previously.
>> and you suggested to apply above flag.
>>
>> If we use 2009q1 then we face no problem on corrupt symbols system.map file
>> I have checked the file in GCC source code of ipa-cp.c file i.e
>>
>> gcc-trunk-4.4]$ vi gcc/ipa-cp.c  in both the release of codesourcercy
>> and found that there is no change in this file.
>>
>> So will you pls let me know, what makes work without   -fno-ipa-cp on
>> 2009q1, and what is such changes that we require
>> to disable of functionality.
>
> Please send mail to the list, not to me directly.  Thanks.
>
> First, questions about the CodeSourcery toolchain should be directed
> to CodeSourcery.
>
> Second, as I recall, several different people said that you should not
> worry about these symbols.  It is a bug in the Linux kernel build that
> some script complains about them.
>
> Third, ipa-cp.c works by creating new functions, and it is those
> functions which cause the problem.  What has changed is presumably the
> names used for those new functions.
>
> Ian
>

Re: gcc4.4.1 related doubt

[trisha yad]

On Thu, Apr 15, 2010 at 7:46 PM, Ian Lance Taylor <iant@google.com> wrote:
> trisha yad <trisha1march@gmail.com> writes:
>
>> This is regarding issue of  -fno-ipa-cp on code sourcercy 2009q3-67.
>> We discuss this on mailing list previously.
>> and you suggested to apply above flag.
>>
>> If we use 2009q1 then we face no problem on corrupt symbols system.map file
>> I have checked the file in GCC source code of ipa-cp.c file i.e
>>
>> gcc-trunk-4.4]$ vi gcc/ipa-cp.c  in both the release of codesourcercy
>> and found that there is no change in this file.
>>
>> So will you pls let me know, what makes work without   -fno-ipa-cp on
>> 2009q1, and what is such changes that we require
>> to disable of functionality.
>
> Please send mail to the list, not to me directly.  Thanks.
>
> First, questions about the CodeSourcery toolchain should be directed
> to CodeSourcery.
>
> Second, as I recall, several different people said that you should not
> worry about these symbols.  It is a bug in the Linux kernel build that
> some script complains about them.
>
> Third, ipa-cp.c works by creating new functions, and it is those
> functions which cause the problem.  What has changed is presumably the
> names used for those new functions.
>
> Ian
>