[adtools] Re: questions about the GCC port
- From: Andrija Antonijevic <antony@xxxxxxxxxxxxxxxxx>
- To: adtools@xxxxxxxxxxxxx
- Date: Wed, 3 Aug 2005 16:56:32 +0200 (CEST)
On 1-Aug-2005, Gunther Nikl wrote:
On Fri, Jul 29, 2005 at 07:24:12PM +0200, Andrija Antonijevic wrote:
Probably nobody wanted to override the generic [TARGET_CPU_CPP_BUILTINS]
defintion. IMHO using a custom defintion isn't a difficult issue.
OK.
Now I am leaning more towards keeping the current implementation at least
for now :-)
Hehe, OK.
BTW, besides HEAD which is currently for gcc 4.0.1, there is also
AMIGA_GCC_3 branch for gcc 3.x.x since 4.0.1 currently expiriences
internal compiler errors when compiling some C++ code.
Maybe this is a generic error? You should check against FSF version.
I am still using older GCC versions only.
The error is unrelated to our changes: I built a powerpc-linux compiler
straight from the officiar tarball and it also had the same problem with a
test file I used. I have reported this on the GCC Bugzilla, but the status of
the report is still "unconfirmed". Probably noone tried reproducing it
because of lack of this sort of hardware and/or includes/libraries for the
powerpc-linux cross compiler. I thought about providing (links to)
includes/libs (f. ex. from Debian) and a step by step instructions how to
reproduce this, but it will have to wait until there's some free time.
I suppose the files in AMIGA_GCC_3 branch needn't be updated right
away until we settle for the changes in the HEAD.
Backporting to 3.4.x shouldn't be a big issue. AFAICT 3.4.x and 4.0.x
are compatible in this area.
Yes, amigaos.c/amigaos.h are almost completely the same, just a few different
lines.
One could pass "-mcrt=clib2" to the compiler if no -mcrt= was given.
Is this possible through the specs file? I mean, I know it's possible to
do it f. ex. like below with amigaos_crt_string, but I think it wouldn't
propagate to the specs file.
Thats correct. You would have to specify the default for every program
(compiler, linker) and you can't test for such injected arguments.
That was what I feared.
Also, I believe I have tested something like %{!mcrt=*: -mcrt=newlib},
but it didn't work. Is there a way to do it?
Your example does what one would expect, it passes -mcrt=newlib if no
other mcrt= options was given.
Yep, but there is one thing that I didn't expect - the context is changed. F.
ex. if no -mcrt option is given and
%{!mcrt=*: -mcrt=invalid} %{-mcrt=*: %eBlah}
is added to the specs file f. ex. in link and/or cpp_os_default string, the
Blah "error" won't be reported, "invalid C runtime library" error won't be
reported and the program will be compiled/linked with clib2 (ie. "you can't
test for such injected arguments", as you wrote above). Also, I seem to
remember that the linker would report an error about unrecognized emulation
mode or something.
So the context is changed in the sense that when -mcrt is inserted as above
the inserted arguments can't be tested for and, unlike the situation where
-mcrt is specified on the compiler command line, it is passed to linker which
doesn't know what to do with it.
I was hoping that it would be possible to add f. ex. default_amiga_crt string
which would just specify -mcrt=xxx and it would be easily changeable, but
this is obviously impossible.
If there is, then multilib building would be a bit easier, it would be
possible to tell it that default option is -mcrt=xxx (or -mcrt=default
and that -mcrt=default is equivalent to -mcrt=xxx).
Let me state, that I don't have any experience with multilib. The m68k
port never used that. The 68k port used the the multilib infrastructure
to build several flavours of libgcc.a. The selection which to use was
done by the linker. I don't know how exactly multilib works.
Probably only those who wrote it know that ;)
What I would like to do with multilib is to say: default is f. ex.
-mcrt=clib2, other options are -mcrt=clib2-ts, -mcrt=newlib, -msoft-float,
-mbaserel. Build [combinations that make sense] and put them to
lib/(clib2|clib2-ts|newlib)/(|soft-float|baserel).
The only problem with this is that default goes to lib and I didn't see a
way to specify where the default should go with MULTILIB_* specifiers. So,
it would build lib/*.a, lib/soft-float/*.a, lib/baserel/*.a for f. ex.
clib2 and lib/newlib/*.a, lib/newlib/soft-float/*.a and
lib/newlib/baserel/*.a.
That would be fine, I guess (we would still continue to use full hierarchy
inside SDK: where the C libraries are installed, only things inside GCC:
would be placed like this) but it would make it impossible to change the
default C lib through the specs file.
You mean by editing the specs file later? Thats indeed impossible.
AFAICT such a change needs a recompile. I am afraid I can't help
with these issues.
No problem, the discussion is leading somewhere, at least :) Changing the
default CRT does work, but there is a price to pay for that when building it.
--- rs6000/amigaos.c ---
const char *amigaos_crt_string="clib2";
--- rs6000/amigaos.c ---
I *think* this can be done by replacing
{ "crt=", &amigaos_crt_string, N_("Select C runtime library"), 0},
with
{ "crt=", &amigaos_crt_string, N_("Select C runtime library"), "clib2"},
I haven't seen any port doing it that way, eg. SUBTARGET_OPTIONS in
rs6000/sysv4.h uses "0" there and sets eg. rs6000_abi_name in
SUBTARGET_OVERRIDE_OPTIONS (4.1 initializes at the declaration).
Sure, that's just as good way to do it. I was worried that
char *amigaos_crt_string="clib2";
{ "crt=", &amigaos_crt_string, N_("Select C runtime library"), 0},
wouldn't do what's expected. Here's the quote from the documentation:
Here is a variant of the above that allows the user to also specify
just `-mshort-data' where a default of `"64"' is used.
extern char *m88k_short_data;
#define TARGET_OPTIONS \
{
...
{"short-data", &m88k_short_data, "", "64"},
}
So, I thought that even if char *amigaos_crt_string="clib2" was used,
amigaos_crt_string would be set to default value (ie. 0) when the parser got
to parsing it. Doing it in SUBTARGET_OVERRIDE_OPTIONS (more precisely, in
SUB3TARGET_OVERRIDE_OPTIONS in amigaos.h) would work fine, of course :)
Using a define to initialize the default case should probably be done.
The default C lib wouldn't be settable by changing the specs file, then.
I would recommend against changing the meaning of "default".
That's a good point, but this "default" was meant more as "default is what
the user prefers and sets himself" :)
Whether this is a problem depends on the multilib situation and also if
it's possible to specify default -mcrt=xxx line to the compiler like (I
hope) you hinted it's possible above.
I don't know if multilib supports your needs.
Probably not.
Actually, switching them [C lib] on the fly works very well after the
build is completed and the files put to their places. The "only" problems
while are while building:
1) location of the linker libraries which needs to be changed after building
2) c++config.h which doesn't take care of used C lib
3) precompiled C++ header files, same reason as 2)
I have compared the builds done with -mcrt=clib2 and -mcrt=newlib and,
except the binaries and linker libraries, the only differences were
files from 2) and 3).
1) is currently done by hand, but hopefully can be done with multilib
2) is also done by hand, #ifdef __CLIB2__ [contents for clib2] #elif
defined(__NEWLIB__) ... #endif, but I suppose Makefile.am can be changed to
fix this.
Well, I don't think multilib was/is intended for the purpose the OS4
port tries to use it. Switching the runtime environment isn't supported
by GCC. It simply doesn't expect this. AFAIK, multilib was invented to
support different calling conventions or cpu versions.
At this point, I'm leaning towards the suggestion that we decide on default
CRT and don't allow changing it in the specs file. If a user prefers a
non-default CRT, it would always have to be specified on the command line.
From what I understand, multilib is meant to be used to create linker
libraries for incompatible command line options. This should also apply to
-mcrt option.
To sum it up, changing CRT from the command line currently works fine with
problems when building the compiler. The usage of multilib in the build
process would solve almost all problems, but we would have to dump the
possibility to change the default CRT. The only remaining thing to solve
would then be the c++config.h file since it's the only thing that depends on
the CRT used (of course, it's possible that other files that depend on the
CRT will be introduced in future versions of GCC).
3) these need not be built at all
You could use "--disable-libstdcxx-pch" to disable PCH.
Aha, I didn't know that, excellent, thanks!
Andrija
______________________________________________________________________________
Amiga Development tools ML - //www.freelists.org/list/adtools
Homepage...................: http://www.sourceforge.net/projects/adtools
Listserver help............: mailto:adtools-request@xxxxxxxxxxxxx?Subject=HELP
Other related posts:
