[adtools] Re: questions about the GCC port
- From: Andrija Antonijevic <antony@xxxxxxxxxxxxxxxxx>
- To: adtools@xxxxxxxxxxxxx
- Date: Fri, 29 Jul 2005 19:24:12 +0200 (CEST)
On 29-Jul-2005, Gunther Nikl wrote:
On Thu, Jul 28, 2005 at 07:55:32PM +0200, Andrija Antonijevic wrote:
On 28-Jul-2005, Gunther Nikl wrote:
Its probably also a good idea to move some stuff into
TARGET_CPU_CPP_BUILTINS.
I think that builtin_define_std ("PPC") and two builtin_assert's should
probably stay since they are also in the same place in sysv4.h
As for powerpc and __powerpc__ builtin_define's (well, they would merge
into one builtin_define_std), your suggestion does make sense. On the
other hand, every config file from rs6000 that defines __powerpc__,
does it in TARGET_OS_CPP_BUILTINS. In short, I have no idea :)
Probably nobody wanted to override the generic defintion. IMHO using
a custom defintion isn't a difficult issue.
OK.
- CPP_<clib>_SPEC: All symbol definitions should be moved into the
compiler since builtin_define_std() knows better how to deal with
-ansi and -std=. Since the used crt is recorded in amigaos_crt_string
thats not all that hard.
That seems like a good idea. Do you know what is the right place to put
this code to?
TARGET_OS_CPP_BUILTINS.
Ah, of course, I ignored the fact that this is a code snippet and not a bunch
of #define's.
I can update these parts.
OK, thanks. 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. I suppose the files in
AMIGA_GCC_3 branch needn't be updated right away until we settle for the
changes in the HEAD.
If -mcrt is not specified, whatever parses amigaos_crt_string would have
to use the default value for clib and that value shouldn't be hardcoded
but read f. ex. from %(crt) specs string. However, I suppose it is
possible for the code to have a specs string evaluated?
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. Also, I believe I have tested something like
%{!mcrt=*: -mcrt=newlib}, but it didn't work. Is there a way to do it?
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).
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.
Currently I hardcoded clib2 as default in all places where it was
needed (I already folded newlib/ixemul/libnix to see if that would
work):
--- rs6000/amigaos.h ---
#define CRT_SPEC "\
%{mcrt=clib2|mcrt=clib2-ts:clib2; \
mcrt=ixemul:ixemul; \
mcrt=libnix:libnix; \
mcrt=newlib|newlib:newlib; \
mcrt=default|!mcrt=*:clib2; \
: %eInvalid C runtime library}"
--- rs6000/amigaos.h --
If the C lib definitions stay separated, CRT_SPEC isn't necessary.
I think all of them should be able to be unified using this, only clib2 will
require special handling. It will probably boil down to %{for clib2:
clib2_specific; all others in one line using %(crt)}
--- 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"},
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.
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.
[C lib handling]
I agree, it is very complicated :I I did it like this since at the time the
specs file was changing wildly and this approach made sure that the specs
for each clib can be modified without changing the structure of the specs
file (there were problems with C++ backend if the structure was changed
since it then used some parts from the builtin specs file and some from
the external specs file).
I can see the benefit from having separate clib definitions.
Heh, yes, but it did become quite huge. The good thing is that it's not often
necessary to read/modify the specs file.
Anyway, things have stabilized a bit now, so I suppose this can be cleaned
up a bit. I'll see to this as soon as I find some time.
I was merely exploring an idea here, although I already tried this idea
in my workspace.
Sure, thinking about possible improvements is always a good thing :)
If you build the ppc-amigaos compiler, you will find that build process is
a bit of a mess: f. ex. libstdc++.a is built only for the default C library
and needs to be moved around etc.
Since every C lib has its own headers I can see that every flavour needs
its own libraries.
Yep. Ideally, the build process would place them into the right location,
right now you have to know what happens and what should happen instead (ie.
build it enough times to stumble upon all build problems and know the next
time).
The goal is to be able to change the default clib, but I'm affraid this
complicates things a lot when using multilib :I
Another thing that needs fixing is c++config.h for different clib's, but
that's another story...
That probably suggests that switching the crt on the fly isn't going to
work reliable. In that case one needs different compiler installation
but thats another set of problems.
Actually, switching them 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.
3) these need not be built at all
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:
