Hans-Peter Nilsson <hans-peter.nils...@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
