Re: CFT: [build] Move libgcc2 to toplevel libgcc

[Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>]

Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:

>> * Again, I noticed an unused target file,
>>   config/cris/cris_abi_symbol.c.  I assume it's a leftover from the
>>   cris-aout port and can go.
>
> As obvious from its contents, yes, put it to rest if you please.

Ok, will do.

>> 	* config/cris/arit.c, config/cris/cris_abi_symbol.c: Move to
>> 	../libgcc/config/cris.
>> 	* config/cris/cris.h: Remove obsolete comment.
>
> Not so obsolete IMO.  Parentheses are still hard to pass through
> shells :) though maybe there's just one layer now?

But we have better mechanisms than passing arbitrary macros through
several layers of make, cf. libgcc/config.host (tm_file), which used to
be gcc/config.gcc (libgcc_tm_file).

> IIUC, this file *is* still included when building libgcc2?

Of course, my patches primarily handled build issues so far, dealing
with the libgcc-only macros in gcc/config is future work.

>>  crisv32-*-linux* | cris-*-linux*)
>>  	tm_file="dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h glibc-stdint.h cris/linux.h"
>> -	# We need to avoid using t-linux, so override default tmake_file
>> -	tmake_file="cris/t-cris cris/t-linux t-slibgcc"
>>  	extra_options="${extra_options} cris/linux.opt"
>>  	case $target in
>>  	  cris-*-*)
>
> Here there was an assignment, not append, to tmake_file.

Right, but the only thing left in tmake_file is t-slibgcc, so no need to
override that.

>> diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h
>> --- a/gcc/config/cris/cris.h
>> +++ b/gcc/config/cris/cris.h
>> @@ -84,11 +84,7 @@ extern int cris_cpu_version;
>>  /* Changing the order used to be necessary to put the fourth __make_dp
>>     argument (a DImode parameter) in registers, to fit with the libfunc
>>     parameter passing scheme used for intrinsic functions.  FIXME: Check
>> -   performance and maybe remove definition from TARGET_LIBGCC2_CFLAGS now
>> -   that it isn't strictly necessary.  We used to do this through
>> -   TARGET_LIBGCC2_CFLAGS, but that became increasingly difficult as the
>> -   parenthesis (that needed quoting) travels through several layers of
>> -   make and shell invocations.  */
>> +   performance.  */
>>  #ifdef IN_LIBGCC2
>>  #define __make_dp(a,b,c,d) __cris_make_dp(d,a,b,c)
>>  #endif
>
> ...well, as long as cris.h is still included and it's truly
> obsolete due to the libgcc move.

As stated above, it is until I (or someone else :-) starts tackling the
macro move to libgcc.

>> diff --git a/libgcc/config.host b/libgcc/config.host
>
>>  *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* | *-*-kopensolaris*-gnu)
>> -  tmake_file="$tmake_file t-crtstuff-pic t-eh-dw2-dip t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver t-linux"
>> +  tmake_file="$tmake_file t-crtstuff-pic t-libgcc-pic t-eh-dw2-dip t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver t-linux"
>>    extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
>
> Hm...
[...]
>>  cris-*-linux* | crisv32-*-linux*)
>> -	tmake_file="$tmake_file t-fdpbit cris/t-linux"
>> +	tmake_file="$tmake_file cris/t-cris t-fdpbit cris/t-linux"
>>  	;;
>
> But here you append to tmake_file.  Is the new "generic" linux
> tmake_file really safe?  What was I was trying to avoid... oh,
> the "SHLIB_MAPFILES += $(srcdir)/config/libgcc-glibc.ver"?
> Should have been safe all along; none of those symbols were
> defined.  Anyway looks like I could need that config/t-linux

This should be dealt with by the shlib patch

	http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00915.html

that deals with this in libgcc/config/cris/t-linux:

# Override t-linux default.
SHLIB_MAPFILES = libgcc-std.ver $(srcdir)/config/cris/libgcc-glibc.ver

> so... ok?  But why don't I see a libgcc/config/cris/t-linux at
> r177764 so I can check?  It should be pre-existing before your
> previous patch.  Is this on top of more than the previous two
> patches?

Yep, all those patches are on top of each other, as I think I state in
the submissions.

> Ok, I'm confused.  I want to wait until the other two patches
> are committed, then look again.  (They are independent if
> serialized, right?)

Yep, that's the intention at least.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University