search

freemint / m68k-atari-mint-gcc

Fork of GNU's gcc with support for the m68k-atari-mint target
https://github.com/freemint/m68k-atari-mint-gcc/wiki
Other
26 stars 7 forks source link

Reintroduce -m68020-60 multilib #8

Closed mikrosk closed 6 years ago

mikrosk commented 6 years ago

I have finally figured it out. Since some time (at least 10 years ago for sure...) m68k gcc has been using a much better but also much more restrictive scheme defined by t-mlibs file which is then referenced by other t-* files.

One of the most painful restrictions is that the whole multilib concept have been reduced to base -mcpu / -march configurations. So in our case, m68020-60 should be defined as an offspring from -march=68020 with -mtune=68020-60 leading to a tree like /usr/lib/m68020/m68020-60.

Unfortunately, that also affects the mappings, there are no longer open to alterations but dynamically generated, again, only for/from the base cpus/archs.

One can't just ignore t-mlibs as before (worked accidentally till now) because t-mlib content is now referenced more or less randomly - I don't understand it for 100% but it seems that gcc is asking the multilib framework for different multilib configurations during compilation. It seems to be working well for the default setting (m68020-60/m5475 multilib) but as soon as one introduces --with-cpu=5475 and needs m68000/m68020-60 multilib, hell breaks loose (as we could see in the release archives).

So this PR maintains the dynamic feature of m68k multilibs while reintroduces m68020-60 as we know it. Unfortunately, the scope of the changes couldn't be kept in t-mint only. :-(

@th-otto, @vinriviere what do you think of it? Can you think of a better way? In the long term, maybe we should really drop support for m68020-60 multilib but in the meantime, this will do.

mikrosk commented 6 years ago

I also didn't want to copy t-mlibs into t-mint to avoid redundancy and risk that we miss an update to that file.

th-otto commented 6 years ago

In the long term, maybe we should really drop support for m68020-60 multilib

Not a good idea i think. For cross-compilers, 68000 should be the default, but you still want to be able to create 020 binaries. Otherwise all the tools in freemint can't be compiled. And multilib configuration also affects which flavours of libgcc.a are generated, so you wouldn't even be able to compile the kernel since that one is always needed.

One of the most painful restrictions is that the whole multilib concept have been reduced to base >-mcpu / -march configurations.

I don't think so. At least in the gcc sub-directory, there are also libraries compiled for m68000/mshort, m68020/mshort etc, and all combinations. In the fastcall patch that i added for experiments to 4.6.4, that adds another level of hierarchy like m68020/mshort/mfastcall, and everything is done almost automatically once you have the definitions set up.

mikrosk commented 6 years ago

@th-otto:

Not a good idea i think. For cross-compilers, 68000 should be the default, but you still want to be able to create 020 binaries.

I didn't mean to drop it solely in favour of 68000 but more like replace it with m68020 or something similar.

I don't think so. At least in the gcc sub-directory, there are also libraries compiled for m68000/mshort, m68020/mshort etc, and all combinations. In the fastcall patch that i added for experiments to 4.6.4, that adds another level of hierarchy like m68020/mshort/mfastcall, and everything is done almost automatically once you have the definitions set up.

Sure, no problem with that. What I meant is that you are not "allowed" to create a custom top-level multilibs, not only for m68020-60 but also for, say, -march=68030 -mtune=68020-40 and give it a custom name like "m68030_20-40". The top level must be from the defined m68k CPU architectures.

mikrosk commented 1 year ago

Adding the relevant thread / bug report for reference: https://sourceforge.net/p/freemint/mailman/freemint-discuss/thread/CAN5rfbSJ9Da8jB-nj6PAAsF8LhTJ-szRA6HyC5nYexAjYDiRaQ%40mail.gmail.com/#msg36423843