Fwd: Re: FW: gcc4.4.1 related doubt

Fwd: Re: FW: gcc4.4.1 related doubt

[David Daney]

Bah!  here is the non bouncing version (I hope).

-------- Original Message --------
Subject: Re: FW: gcc4.4.1 related doubt
Date: Fri, 26 Mar 2010 11:38:20 -0700
From: David Daney <ddaney@caviumnetworks.com>
To: Ian Lance Taylor <iant@google.com>
CC: trisha yad <trisha1march@gmail.com>, Jie Zhang 
<jie@codesourcery.com>,  gcc-help@gnu.org, arm-gnu@codesourcery.com

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: Re: FW: gcc4.4.1 related doubt

[Brian Budge]

Doesn't it seem like fixing the broken scripts might be better?  And
if not, why not?

On Fri, Mar 26, 2010 at 12:34 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> Bah!  here is the non bouncing version (I hope).
>
> -------- Original Message --------
> Subject: Re: FW: gcc4.4.1 related doubt
> Date: Fri, 26 Mar 2010 11:38:20 -0700
> From: David Daney <ddaney@caviumnetworks.com>
> To: Ian Lance Taylor <iant@google.com>
> CC: trisha yad <trisha1march@gmail.com>, Jie Zhang <jie@codesourcery.com>,
>  gcc-help@gnu.org, arm-gnu@codesourcery.com
>
> 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

[David Daney]

On 03/26/2010 01:05 PM, Brian Budge wrote:
> Doesn't it seem like fixing the broken scripts might be better?

Probably you are right.

> And if not, why not?
>

No good reason that I can think of.

I would note, that the current Linux kernel HEAD does not suffer this 
problem.  There was however a window between when the bogus warning 
messages were added to the kernel build scripts and the release of a GCC 
version that triggered the issue.  Once the kernel hackers realized 
there was a problem, they fixed it.  People using the kernel versions in 
the window either have to use older GCCs or fix their build scripts if 
they don't want to see the messages.

Fixing the kernel build scripts is not difficult, but I forgot what I 
did, so it is left as an exercise for the enterprising reader.

David Daney

> On Fri, Mar 26, 2010 at 12:34 PM, David Daney<ddaney@caviumnetworks.com>  wrote:
>> Bah!  here is the non bouncing version (I hope).
>>
>> -------- Original Message --------
>> Subject: Re: FW: gcc4.4.1 related doubt
>> Date: Fri, 26 Mar 2010 11:38:20 -0700
>> From: David Daney<ddaney@caviumnetworks.com>
>> To: Ian Lance Taylor<iant@google.com>
>> CC: trisha yad<trisha1march@gmail.com>, Jie Zhang<jie@codesourcery.com>,
>>   gcc-help@gnu.org, arm-gnu@codesourcery.com
>>
>> 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
>>
>

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

[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

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

[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

[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,

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