headers
Ian Lance Taylor | 1 Oct 2009 02:08
Picon
Favicon
Gravatar

Re: libgcc_s.so.0 on HP-UX

Leonardo <sombriks <at> gmail.com> writes:

> is possible to compile using gcc but don't have dependencies on
> libgcc_s.so.0,libunwind.so.1 and so on?

Strictly speaking, yes, it is possible.  A program which is simply
"int main() { }" will normally not need those libraries.  On
GNU/Linux, when using sufficiently new versions of the linker, gcc
will use the --as-needed linker option so that the libraries are only
marked as required when they are, in fact, required.

However, gcc does require functions from those libraries for various
different purposes.  If gcc generates code which needs those
libraries, then those libraries will be needed, and there is nothing
useful to be done about it.

Ian
Permalink | Reply | 0 comments |
headers
Ian Lance Taylor | 1 Oct 2009 02:38
Picon
Favicon
Gravatar

Re: Numeric suffixes on symbols

Michael Morrell <morrell <at> alumni.ucsd.edu> writes:

> I'm building some code that I want to make sure produces the same bits each
> time.  I ran into a case where the only difference between the result from
> two different compilation is the names of some of the symbols.
>
> For example, I may see the symbol name:
>
>   __PRETTY_FUNCTION__.20638
>
> in the first build, and then:
>
>   __PRETTY_FUNCTION__.20694
>
> in the second build.
>
> I can believe that gcc might need to generate a suffix to disambiguate
> function-scoped static variables with the same name, but I need it to do
> so in a deterministic fashion.  Over a large code base, this only shows
> up a few times, so that seems strange.
>
> Can someone help to explain this or point me towards the place in the
> compiler where it is generating this suffix?

The number comes from DECL_UID in lhd_set_decl_assembler_name.

That should normally be fixed for a single compilation, but it is
likely affected by some compiler options.

Ian
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicholas Sherlock | 1 Oct 2009 06:04
Picon

Re: Numeric suffixes on symbols

Michael Morrell wrote:
> I'm building some code that I want to make sure produces the same bits each
> time.  I ran into a case where the only difference between the result from
> two different compilation is the names of some of the symbols.
> 
> For example, I may see the symbol name:
> 
>   __PRETTY_FUNCTION__.20638
> 
> in the first build, and then:
> 
>   __PRETTY_FUNCTION__.20694
> 
> in the second build.

I'm not sure if it will solve your problem, but GCC has a command-line 
option for setting the random seed it uses to generate at least some 
symbol names:

-frandom-seed=string
     This option provides a seed that GCC uses when it would otherwise 
use random numbers. It is used to generate certain symbol names that 
have to be different in every compiled file. It is also used to place 
unique stamps in coverage data files and the object files that produce 
them. You can use the -frandom-seed option to produce reproducibly 
identical object files.

     The string should be different for every file you compile.

http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
naveen yadav | 1 Oct 2009 08:01
Picon

gcc-4.3.3 with MIPS generate relocation type 0x7f (127) which is unknown

Hi All ,

I am using  prelink-0.0.20090311 for MIPS with gcc 4.3.3.
mips-4.3 toochain generates .rel.plt section that has entries with
relocation type 0x7f (127) which is unknown.
This Assigned virtual address space slots for libraries:
/lib/ld.so.1                                                 2c000000-2c030a24
/prelink_test/libtest1.so.0                                  2c040000-2c2c4e90
/lib/libc.so.6                                               2c2d0000-2c43dc60
Prelinking /lib/ld-2.5.90.so
Prelinking /lib/libc-2.5.90.so
Prelinking /prelink_test/libtest1.so
Prelinking /prelink_test/test1
prelink.host: /prelink_test/test1: Unknown MIPS relocation type 1663
prelink.host: reloc.c:174: convert_rel_to_rela: Assertion `d->d_size
== dso->shdr[i].sh_size' failed.
./build.sh: line 27: 18246 Aborted                 prelink.host
--root=../ --verbose --config-file=/etc/prelink.conf
--cache-file=/etc/prelink.cache --ld-library-path=/prelink_test -x
mips24ke_nfp_be-ldd prelink_test/test1
Laying out 1 libraries in virtual address space 2c000000-3c000000
Assigned virtual address space slots for libraries:

But prelink version prelink-0.0.20090311 works fine with gcc 4.2.2.
Will you pls suggest what is reason...

Best Regards
Naveen
(Continue reading)

Permalink | Reply | 1 comment |
headers
naveen yadav | 1 Oct 2009 08:04
Picon

GCC-4.3.3 with MIPS crossed generate relocation type 0x7f (127) which is unknown

Hi All ,

I am using  prelink-0.0.20090311 for MIPS with gcc 4.3.3.
mips-4.3 toochain generates .rel.plt section that has entries with
relocation type 0x7f (127) which is unknown.

This Assigned virtual address space slots for libraries:
/lib/ld.so.1                                                 2c000000-2c030a24
/prelink_test/libtest1.so.0                                  2c040000-2c2c4e90
/lib/libc.so.6                                               2c2d0000-2c43dc60
Prelinking /lib/ld-2.5.90.so
Prelinking /lib/libc-2.5.90.so
Prelinking /prelink_test/libtest1.so
Prelinking /prelink_test/test1
prelink.host: /prelink_test/test1: Unknown MIPS relocation type 1663
prelink.host: reloc.c:174: convert_rel_to_rela: Assertion `d->d_size
== dso->shdr[i].sh_size' failed.
./build.sh: line 27: 18246 Aborted                 prelink.host
--root=../ --verbose --config-file=/etc/prelink.conf
--cache-file=/etc/prelink.cache --ld-library-path=/prelink_test -x
mips24ke_nfp_be-ldd prelink_test/test1
Laying out 1 libraries in virtual address space 2c000000-3c000000
Assigned virtual address space slots for libraries:

But prelink version prelink-0.0.20090311 works fine with gcc 4.2.2.

Will you pls suggest what is reason...

Best Regards
Naveen
(Continue reading)

Permalink | Reply | 8 comments |
headers
Greg Ryan | 1 Oct 2009 08:05
Picon
Picon

gcc 4.4.1 under Solaris 10 Ultrasparc - build problems

I have been unsuccessful building gcc 4.4.1 on a Sparc Enterprise T5120
running Solaris 10.  Having not built any Solaris versions of gcc for
many years, I'd appreciate any pointers this group might have.

This Sun system comes with gcc version 4.0.4 (gccfss).

Starting with gmp-4.3.1, I was able to successfully build and check the
package with the preinstalled gcc.  Similarly, mpfr-2.4.1 successfully
built and checked with this compiler.

On to gcc 4.4.1, I ran the configure with:

	../configure CC='gcc -m64' --prefix=/gnu/usr/gcc-4.4.1 --without-gnu-as
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-mpfr=/local/usr
--with-gpm=/local/usr --enable-languages=c,c++

Without the 'gcc -m64' configure complained that GMP and MPFR weren't in place
as the configure test attempted a 32 built compile.  When I ran

	make bootstrap

the build failed in the following way:

[from the output of the make]
	checking for sparc-sun-solaris2.10-gcc...
/local/src/gcc-4.4.1/SunOS-5.10-sun4v/objdir/./gcc/xgcc
-B/local/src/gcc-4.4.1/SunOS-5.10-sun4v/objdir/./gcc/
-B/gnu/usr/gcc-4.4.1/sparc-sun-solaris2.10/bin/
-B/gnu/usr/gcc-4.4.1/sparc-sun-solaris2.10/lib/ -isystem
/gnu/usr/gcc-4.4.1/sparc-sun-solaris2.10/include -isystem /gnu/usr/gcc-4.4.1/sparc-sun-solaris2.10/sys-include
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ian Lance Taylor | 1 Oct 2009 08:20
Picon
Favicon
Gravatar

Re: gcc-4.3.3 with MIPS generate relocation type 0x7f (127) which is unknown

naveen yadav <yad.naveen <at> gmail.com> writes:

> I am using  prelink-0.0.20090311 for MIPS with gcc 4.3.3.
> mips-4.3 toochain generates .rel.plt section that has entries with
> relocation type 0x7f (127) which is unknown.

The mailing list is gcc-help <at> gcc.gnu.org, no need to send e-mail to
gcc-help <at> gnu.org.

0x7f (127) is a R_MIPS_JUMP_SLOT relocation used to support non-PIC
executables of MIPS targets.  See
http://sourceware.org/ml/binutils/2008-07/msg00008.html .

Somebody is going to have to update prelink to handle this, assuming
it hasn't been done already.

Ian
Permalink | Reply | 0 comments |
headers
kito | 1 Oct 2009 09:19
Picon

About Conditional Execution Pattern

Hello everybody,
I have some question about Conditional Execution Pattern.
In fact, I want to remove Conditional Execution in ARM for experimentation.
I have remove lots of Conditional Execution Pattern from arm.md
But I see a RTX that I can't understand.

 <at> (insn 74 79 80 ../../../gcc-live/libgcc/../gcc/libgcc2.c:1848 (set
(reg:QI 18 r18 [320])
 <at>         (const_int 1 [0x1])) 169 {*arm_movqi_insn}
(expr_list:REG_EQUAL (const_int 1 [0x1])
 <at>         (nil)))
	mov	r18, #1	 <at>  74	*arm_movqi_insn/1	[length = 4]
 <at> (jump_insn 80 74 729 ../../../gcc-live/libgcc/../gcc/libgcc2.c:1848 (set (pc)
 <at>         (if_then_else (ne (reg:CC 40 cc)
 <at>                 (const_int 0 [0x0]))
 <at>             (label_ref 83)
 <at>             (pc))) 220 {*arm_cond_branch} (expr_list:REG_DEAD (reg:CC 40 cc)
 <at>         (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
 <at>             (nil)))
 -> 83)
 <at> (insn 82 729 83 ../../../gcc-live/libgcc/../gcc/libgcc2.c:1848 (set
(reg:QI 18 r18 [320])
 <at>         (const_int 0 [0x0])) 169 {*arm_movqi_insn}
(expr_list:REG_EQUAL (const_int 0 [0x0])
 <at>         (nil)))
	moveq	r18, #0	 <at>  82	*arm_movqi_insn/1	[length = 4]

I don't know the expr_list:REG_EQUAL is how to generate, I have seem
it in expand pass.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rajat | 1 Oct 2009 09:54
Picon
Favicon

Re: GCC 4.1.2 Vs 3.4.6

>> I think you meant 4.1.2, as you said in your title.

Sorry for the typo, I meant 4.1.2.

>> This is not an attractive choice, particularly if you use languages
other than C, or wish to optimize for CPUs introduced in the last 2
years.  I suppose 3.4.6 is there primarily for 
>> compatibility with RHEL
4, while even 4.1 is out of date now.

Yeah the application includes C and C++ both. 

>> If you are choosing a new gcc version for new projects, you might
consider installing current released versions of gcc and binutils.

Yeah I am planning to use a newer gcc version which can go well with RHEL 5. So apparently gcc 4.4.1 seems to be
the latest, do you suggest me to go for it ?

 Thanks,
Rajat.

----- Original Message ----
From: Tim Prince <n8tm <at> aol.com>
To: Rajat <myself_rajat <at> yahoo.com>
Cc: gcc-help <at> gcc.gnu.org
Sent: Wednesday, September 30, 2009 6:57:09 PM
Subject: Re: GCC 4.1.2 Vs 3.4.6

Rajat wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Ruottu | 1 Oct 2009 10:31

Re: gcc 4.4.1 under Solaris 10 Ultrasparc - build problems

Greg Ryan wrote:

> I have been unsuccessful building gcc 4.4.1 on a Sparc Enterprise T5120
> running Solaris 10.  Having not built any Solaris versions of gcc for
> many years, I'd appreciate any pointers this group might have.
> 
> This Sun system comes with gcc version 4.0.4 (gccfss).
> 
> Starting with gmp-4.3.1, I was able to successfully build and check the
> package with the preinstalled gcc.  Similarly, mpfr-2.4.1 successfully
> built and checked with this compiler.

Producing new gmp and mpfr versions for GCC can happen in two ways :

1. one wants to do this one at a time, building, installing and testing
    these before doing the same with bare GCC

2. building all these at the same time during the GCC build

You choosed the first way. When your target,'sparc-sun-solaris2.10', is
a 'bi-arch' target, the 32-bit host/target being the default, you should
build 32-bit versions of gmp and mpfr because the GCC binaries would be
32-bit as default.

> On to gcc 4.4.1, I ran the configure with:
> 
> 	../configure CC='gcc -m64'

This causes the 32-bit default being overridden...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane